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ABSTRACT 


Detailed information and intellectual understanding of a network’s topology and 
vulnerabilities is invaluable to better securing computer networks. Network protocol 
analyzers and intrusion detection systems can provide this additional information. In 
particular, game-based trainers, such as CyberCIEGE, have been shown to improve the 
level of training and understanding of network security professionals. This thesis’ 
objective is to enhance these applications by developing NTAV3D, or. Network 
Topology and Attack Visualizer (Three Dimensional). 

NTAV3D is a tool that displays network topology, vulnerabilities, and attacks in 
an interactive, three dimensional environment. This augments the design and gameplay 
of CyberCIEGE by increasing gameplayer interaction and data display. Additionally, 
NTAV3D can be expanded to provide this capability to network analysis and intrusion 
detection tools. Eurthermore, NTAV3D expands on ideas and results from related work 
of the best ways to visualize network topology, vulnerabilities, and attacks. 

NTAV3D was created using open-source software technologies including Xj3D, 
X3D, Java, and XML. It is also one of the first applications to be built with only the 
Xj3D toolkit. Therefore, the development process allowed evaluation of these 
technologies, resulting in recommendations for future improvements. 
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I. 


INTRODUCTION 


A. BACKGROUND 

Computer networks are the intereonnections of one or more computers for the 
purposes of communicating and sharing resources. Often, these networks can connect a 
myriad of disparate hardware systems. Thus, securing and managing these networks can 
become a daunting task. This is especially true for an inexperienced network 
administrator. One way this issue is addressed is increased training for both the novice 
and expert network manager. 

However, part of the difficulty in network management and security in general 
involves being able to visualize the network. This concept of network visualization 
involves such aspects as how a network’s components are arranged, otherwise known as 
the network’s topology, as well as its potential vulnerabilities. This is a complex subject, 
and as such, it can become difficult to conceptualize a network’s level of security. By 
gaining a better understanding of a network’s topology and vulnerabilities, it is hoped 
that both the networking student, and professional network administrator can gain a better 
awareness for the networks they are trying to secure. 

1. CyberCIEGE 

One effort to provide enhanced, effective training is the information assurance 
training tool CyberCIEGE. This is a computer game-based trainer developed by 
collaboration between The Center for Information Systems Security Studies and Research 
(CISR) at the Naval Postgraduate School (NPS) and Rivermind, Inc. Its development 
was sponsored by the Naval Education and Training Command, the Office of Naval 
Research, and the Office of the Secretary of Defense. Through this tool, network security 
and management can be taught in a more stimulating and interactive way. The goals of 
the game are clear from its initial title video. It poses the question, “Can you keep the 
network alive?” The program provides players with the ability to setup and defend 
networks, and to see a visual representation of the consequences of the decisions they 
make both before and after attacks on the network. 
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2. X3D: Extensible 3D Graphics 

X3D, or Extensible 3D Graphies, is an open-souree, royalty free file format and 
run-time arehiteeture that is used to display three dimensional graphies (What Is X3D?, 
May 2007). X3D is also an ISO (International Organization for Standardization)-ratified 
standard, whieh means it has industry baeking as an aeeepted format for displaying three 
dimensional graphies. X3D is based on the Extensible Markup Eanguage, or XML, 
whieh makes it well suited for programmatie parsing (see Chapter III for more 
information on XML). 

3. Xj3D 

Xj3D is the Java-based applieation programming interfaee (API) that was used to 
develop the software product of this thesis. The Xj3D project exists as both a 
programming toolkit, and as a stand-alone browser that can load and manipulate the 
previously mentioned X3D or VRML (Virtual Reality Modeling Language) graphics files 
(Xj3D Project, 2006). Lor the purposes of this thesis, the Xj3D API, known as the SAI, 
or Scene Access Interface, is used to create an X3D scene graph entirely within Java 
code. The Xj3D browser is then programmatically implemented as an application that 
can be embedded within CyberCIEGE, or launched separately to display the scene graph 
produced. Additionally, for those only familiar with implementing X3D in its typical 
stand-alone file format. Appendix A provides a list of the X3D node types that are 
programmatically implemented in the thesis software product. 

4. Network Tools 

Many network tools exist that administrators and students can utilize to study, 
analyze, and defend computer networks. One such group of software is referred to as 
network protocol analyzers, or “packet sniffers.” An example of a very popular packet 
sniffer is Wireshark (formerly known as Ethereal). This application can be downloaded 
at http://www.wireshark.org (accessed May 2007). There also exists software that can 
help network administrators detect intrusions or network attacks that may be occurring in 
a network. A software package of this type is often known as an Intrusion Detection 
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Systems, or IDS. One example of such a program is Snort, available at 
http://www.snort.org (accessed May 2007). Chapter II provides additional information 
about network tools. 


B. WHY A NETWORK VISUALIZATION TOOL IS NEEDED 

CyberCIEGE presents a three dimensional virtual office or military command 
environment that allows players to see users, their computers, and the office layout. 
However, this “office view” does not depict network connections. The network topology 
is viewed in a separate screen, and the current network view in CyberCIEGE is a two 
dimensional view. The placement of components in this view does not correspond to 
their actual placement in the office view of the game. An additional problem arises with 
respect to players’ ability to visualize network attacks. Currently, a short video clip is 
played after network attacks occur that explains the various types of attacks and how they 
evolve. This video clip is generalized to cover all attacks and is not specific to the attack 
that occurred or the scenario being played. 

Additionally, many of the aforementioned network analysis and intrusion 
detection systems that can be downloaded from the web, such as Snort or Wireshark, 
have limited or no integrated visualization capabilities. These packages are not able to 
create a visual display (let alone a three dimensional one) of the network topology based 
on the information obtained from packets traveling in the networks. Additionally, visual 
representation of packet paths is not currently implemented in these packages. Thus, 
when a network security issues arises, it can become difficult to conceptualize the 
networks nodes affected, as well as the path the attack itself is taking through the 
network. 

C. GOALS AND PROPOSED SOLUTIONS 

I. Goals 

a. CyberCIEGE Enhancement 

The motivation for this thesis stems from the enhancement of 
CyberCIEGE as a network security trainer. This will be accomplished by augmenting the 
simple two-dimensional representation of network topology currently implemented in the 
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game with an interactive, three dimensional visualization tool, allowing game players to 
see the networks they create from any angle. It is hoped that by providing players with 
an interactive, three-dimensional visualization, they will be able to gain a better sense of 
network interconnections created in the scenario being played, and a better understanding 
of information flow involved in network attacks. This kind of information can be 
invaluable in learning how to best setup and defend computer networks from attack. 

b. Intrusion Detection Tool Enhancement 

In addition to providing an enhanced visualization application to 
CyberCIEGE, the thesis will pursue how its software application can be used to visualize 
networks and traffic flows. The input for this will be derived from intrusion prevention 
and detection systems and network protocol analyzers such as Snort or Wireshark. 
Conceivably, the added feature of being able to visually "see" the networks one is trying 
to analyze and defend, and the flow of data within these networks would be extremely 
beneficial to users. It is hoped that the users of these software packages can gain 
increased “situational awareness” and an overall better appreciation for the networks they 
are studying, analyzing, and ultimately, trying to defend from attack. 


c. Visualization Tools Evaluation 

A further goal is to evaluate the capabilities of the Xj3D SAI for 
programmatically creating three-dimensional visualizations. Currently, there are only a 
small number of projects created thus far that implement X3D via Xj3D purely 
programmatically, and without loading and manipulating individual X3D files. This 
method of X3D application is quite different from creating, loading, and manipulating a 
stand-alone X3D file. Therefore, this thesis will seek to explore how well Xj3D performs 
in this capacity, and will provide a framework for how the technology can be 
implemented. 
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2. Proposed Solutions 

To address the goals in the previous seetion, the authors will design and develop a 
Network Topology and Attaek Visualizer (Three Dimensional), whieh will be referred to 
as NTAV3D throughout this doeument. The main objeetive of the NTAV3D application 
is to be a network visualization tool that allows network administrators, and those 
interested in learning about securing networks a way to conceptualize this complex 
system of computing. NTAV3D will provide a three-dimensional view that correlates to 
the “office view” in CyberCIEGE, but that focuses on network interconnections between 
components. The tool will then display the actual flaws and malicious software that may 
exist on these components, while also conveying which asset or assets were attacked and 
how they were attacked. A framework will then be developed for how NTAV3D could 
interact with some of the network tools mentioned above to provide similar 
visualizations. 

D. LIMITATIONS 

Visualizing the actual origins of cyber attacks is a related, but separate problem 
that is outside the scope of this thesis, and therefore is not included in NTAV3D’s 
capabilities or the discussion therein. 

Additionally, utilizing NTAV3D to provide network visualization to IDS or 
protocol analyzers is comparatively more difficult than providing the visualization to 
CyberCIEGE. Chapter V will further address these specific limitations. 

Einally, NTAV3D is not meant to perform as a network topology and 
management, or optimizer, tool. Other tools already exist in these areas that allow 
network administrators to manage and optimize their networks. Products, such as 
Hewlett-Packard’s “HP OpenView,” and SolarWinds suite of network management tools 
are examples of applications that meet this need. More information on these tools can be 
found at http://h20229.www2.hp.com and http://www.solarwmds.net respectively (both 
accessed May 2007). 
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E. THESIS ORGANIZATION 

Chapter II reviews baekground information in network visualization, ineluding 
how networks and network attaeks have been visualized in the past. This information is 
reflected in how the NTAV3D visualizations are implemented. Chapter III provides 
background on the application technologies that were used to develop NTAV3D. 
Additionally, it explains the decisions that were made with regard to the use of each 
technology. Chapter IV explains the decisions made for the thesis visualization 
application, based partly on feedback, and the research of Chapter II. Chapter V 
discusses how the technologies previously introduced were actually used to implement 
the visualization, as well as evaluations of these technologies. Finally, Chapter VI 
provides recommendations for future work as well as suggests ways the NTAV3D 
application can be expanded and improved. The chapter also includes the results of this 
thesis, and evaluations on the success of the implementation detailed in this document. 
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II. NETWORK VISUALIZATION BACKGROUND 


A. WHAT IS VISUALIZATION 

Visualization can be defined as the cognitive process, performed by human 
beings, whieh brings meaning to data (Spence, 2001; Keller, 1993). When performed by 
a human, visualization is aehieved by creating an ephemeral mental model. Mental 
models created by humans are cannot be easily shared or reprodueed, whereas a 
visualization ereated via a eomputer is reproducible and easily distributed. It is important 
that a visualization be reprodueible and distributable so that a large number of people ean 
benefit from it. With this in mind, the context of the term visualization throughout the 
remainder of this thesis will refer to a visualization constructed via computer. Seientilie 
visualization is a related field where physieal objects or phenomena are represented, 
usually in simulated 3D (Spence, 2001). The goal of any visualization is to improve the 
user’s understanding of the subject. The basie proeess of visualization is depicted in the 
figure below. 
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Figure 1. The visualization proeess (From Holmberg et al, 2006). 

The figure above illustrates the basie visualization proeess beginning with the 
data set, whieh is converted to a visual representation to enhanee the end user’s 
understanding of the data set. There are two elements that comprise the basic framework 
of every visualization. These elements are the datasets and the visual representation 
method. 

I. Datasets 

The origin of a data set can come just about anywhere, but the most common 
origins are from laboratory or simulation data, or output from sensors out in the field. 
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The data is usually in the form of a series of numbers. Although data in the form of 
numbers is useful when performing a look up or a comparison, forming an ephemeral 
model from them is difficult. The difficulty can often time be attributed to the sheer size 
of the data. Employing a computer visualization helps to overcome the size difficulty 
and facilitate the ephemeral model building process. 

2. Representation Methods 

There are numerous methods for visually presenting numbers with pie charts, bar 
graphs, scatter plots, and histograms being some of the most common. Every method has 
strengths and weaknesses. There is no perfect presentation method that will adequately 
visualize all the different types of data that exist. The correct representation method is 
dependent upon the data. 


a. Parallel Coordinate, Mosaic, and HyperBox Plots 
One method for representing datasets is a parallel coordinate plot where 
each variable is given its own axis. Each line represents a single data entry. This 
representation method can handle quantitative data as well as categorical data. 
Relationships can be obtained by observing the appearance of the plot. The example in 
Eigure 2 has six variables and six data entries. Observing this example plot, it appears 
that a correlation exists between variables B and C because none of the lines between 
them cross and all the lines have very little slope. Eooking at variables A and B, it 
appears that an inverse correlation exists because the lower the point on axis A resulted in 
a larger value on axis B, and vice versa. The ordering of the axis directly influences how 
easily the same inferences can be made. Eollowing the "a" data entry from one end to the 
other can be difficult based on the number of data entries and the number of lines 
crossing. Values can be obtained from the plot if the axes are marked with upper and 
lower bounds. These values would be placed at the top and bottom of each axis. 
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Figure 2. Parallel eoordinate plot with six variables (From Spenee 2001) 

Another representation method is a mosaie plot, which uses rectangles 
with proportional heights and widths based on the data. This technique is useful when 
dealing with high-dimensional data. The example plot in Figure 3 shows data concerning 
the Titanic disaster. 




Smmd J>m4 

Figure 3. Mosaic plot of Titanic data broken down by gender, age, class and 
survival (From Spence 2001) 

The green represents people who survived and the black represents the 
people who died. The top portion of data is females and the bottom is males. The four 
columns represent first class passengers, second class passengers, third class passengers, 
and the crew, respectively. The small second column represents children, next to each of 
the larger columns representing adults. A striking observation is the percentage of 
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women who survived as eompared to men. Many other observations ean be gleaned from 
this figure by simply diseeming patterns or anomalies in the figure. Unless values are 
plaeed within the reetangles, it is diffieult to extract numbers from these plots. 

Both of these methods can be static displays, as depicted in the previous 
two figures, or interactive displays. The interactive versions create new static displays 
based off user interaction. Many people believe that dynamic or interactive graphics are 
invaluable tools, which aid the process of understanding and finding patterns or 
anomalies (Becker, 1990). The reason is that interactive graphics allow the user to see 
the figure from different angles or different configurations. Different views may reveal 
relationships that were not visible in other views. One of these hidden relationships 
could potentially provide the information needed to increase the user’s understanding. 
Additionally, “the Theory of Multiple Intelligences (Gardner, 1985) implies that teaching 
with visual and other components can make learning more effective” (Baxley et al, 
2006). 

A hyperbox (Alpern and Carter, 1991) is constructed such that all possible 
pairs of variables are shown plotted against each other (Spence, 2001). The result 
resembles a solid three-dimensional object with many rectangular faces. Each 
rectangular face is a separate pairing of two variables. Because all possible combinations 
are shown, the ordering problem that arises with the parallel coordinate plots is avoided. 
This method is useful for multivariate data sets. 



Figure 4. A five dimensional hyperbox (From Spence, 2001) 
b. Node and Link Diagrams 

The method of interest for this thesis is a node and link diagram. The 
nodes represent entities of interest and the links represent the relationships between 
entities (Hansen and Johnson, 2004). These relationships include raw physical 
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measurements, computed aggregates, or abstract quantities (Hansen and Johnson, 2004). 
The nodes can be portrayed as boxes, circles, points, or any other glyph—a graphical 
object—^which makes sense for the given visualization (Eick, 1996). Links are normally 
portrayed as lines connecting one node to another. 



( External LAN [) 



Figure 5. 


Example Node link diagram obtained from 

http://www.answers.com/topic/high-availability-cluster on May 21, 2007. 


The example diagram in Figure 5 is a simple representation of a high-availability cluster. 
As seen in the diagram there are a handful of computers, routers, and servers 
interconnected with colored lines. Some of the visualization techniques employed in 
node link diagrams were adopted, but in order to correctly represent the physical layout 
of the network this representation had to be extrapolated into a three-dimensional 
environment. As opposed to connecting components with straight lines as shown in 
Figure 5, it was necessary to devise an alternative connection scheme in order to 
minimize ambiguity and display clutter in the three-dimensional environment. The 
solution and its benefit are discussed in detail in Chapter IV. 


B. CURRENT NETWORK VISUALIZATION RESEARCH 

Because networks are becoming increasingly large and complex, much of the 
research efforts invested in network visualization these days are focused on solving the 


11 






















problems associated with visualizing large networks. These problems include scalability 
and alleviating display clutter, generating the appropriate topology, and achieving real¬ 
time visualization results. The definition of what constitutes a large network may vary 
slightly from source to source, but in the context of this thesis, networks with more than 
100 nodes will be considered large networks. Large networks are not an issue within 
CyberCIEGE because none of the networks created by game players approach the 100 
node mark. Earge networks are likely to be an issue when dealing with output from 
intrusion detection systems in the real world. 

1. Solutions 

a. Reducing Display Clutter 

With a finite amount of display space on a computer screen, visualizing 
the entirety of a large network in manner clearly discernable to the end user is a difficult, 
if not impossible, task to accomplish due to display clutter. The American Heritage 
College Dictionary defines clutter as “a confused or disoriented state, caused by filling or 
covering with objects.” This definition simply means that clutter beings on confusion 
due to the number and spacing of objects within a scene. Scaling the network, 
controlling what is displayed, color coding, and utilizing three-dimensional space are four 
commonly employed methods to reduce display clutter. 

The first common method to reduce the amount of display clutter is to 
scale the large network into a smaller, more manageable size. This method results in a 
smaller, less detailed network that can be displayed in a more clear manner. 

The second common solution applied to this problem is to display only the 
network components that are visible within the current view. This method can be thought 
of as a level-of-detail method where a detailed representation of a particular area is 
shown only when focused upon by the user. The user controls what level of detail is 
shown by navigation through the scene. 

The third method is to use a color coding scheme to represent numerical 
values or other information which may occupy large amounts of screen real estate and 
may also obscure other more important details is another method employed to reduce 
ambiguity in the scene (Kershenbaum and Murray, 2005). By replacing physical 
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numbers with a color coding scheme, the amount of information displayed is reduced, yet 
the amount of information that can be gleaned from the display is not reduced. In 
NTAV3D, li nk s are color coded to visually differentiate between separate networks 
instead statically listing the name of the network next to the line. 

The fourth reduction method is to use a three-dimensional representation 
as opposed to a two-dimensional display. Visualizing in three-dimensional space does 
introduce some different issues. Three-dimensional displays are often times confusing, 
difficult to navigate, and cause the user to loose a sense of overall context (Cox et al, 
1996). One method to mitigate navigational difficulties while maintaining context is to 
restrict the navigation capabilities and make the display as user friendly as possible (Cox 
et al, 1996). Restricting navigation such that the user cannot travel inside a piece of 
geometry and maintaining the camera’s focus on the scene as the user navigates through 
the scene will keep the user from becoming disoriented in the three-dimensional world. 
In NTAV3D, the decision as to how to allow the user to navigate through the scene was 
additionally constrained by maintaining a close relationship to controls already in place 
within CyberCIEGE. Similar control schemes allow the user to transition from one 
application to the other without having to memorize different control patterns. 

b. Generating Correct Topology 

Although reducing display clutter increases the likelihood of information 
being extracted from a visualization, the chosen topological display of the data directly 
impacts the relationships the user is able to take in. 



Figure 6. Two topologies for the same nodes (From Kershenbaum and Murray, 
2005). 
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The model on the right in Figure 6 shows the same relationships was the model on the 
left, but positions the nodes sueh that no lines eross. 


The same nodes displayed in a slightly different topology ean eonvey a 
different meaning. Topologies ean be hand generated, but in most cases, they are 
generated by an algorithm to meet certain criteria. Many algorithms are designed to meet 
one or more of the following criteria: 

• Minimize the number of links crossing 

• Maximize the depiction of symmetry 

• Minimize the number of link bends 

• Maximize the minimum angle between links leaving a node 

• Maximize link orthogonality 

The level of importance for each criterion is based on what is being 
visualized. In cases where physical location is important, the criteria above become 
unimportant because the positions of nodes cannot be changed to meet the 
aforementioned criteria. Geographic data is a good example of when physical location is 
important. Because the physical location of nodes is specified by CyberCIEGE, straight 
lines could not simply be drawn between nodes because eliminating crossing lines was 
also import. This led to the development of a routing algorithm. 

A group of researchers took different approach to placing nodes. Instead 
of using criteria that create an aesthetically pleasing display, such as minimizing the 
number of crossing links, these researchers looked into developing an algorithm that 
takes into account the weight (strength) of the li nks (Eick and Wills, 1993). With this 
approach, the strength of the link between two nodes is what determines their relative 
position from one another. They determined that the algorithm would have an inverse 
relationship such that nodes connected by stronger links would be closer together than 


14 



nodes connected by weaker links. The desired inverse relationship is achieved by 
directly minimizing the function 

i:(Wy-l/dy)'= i:(dyWy-l)Vd,/ 

where Wij is the weight of the link and dij is the displayed length of the link (Eick and 
Wills, 1993). 

The developed algorithm also takes advantage of hierarchical relationships by placing 
the root node then placing all the sub-networks generated by its children. 

A variety of other tools exist that focus solely on the generation of 
network topologies. BRITE is a free topology generation tool from Boston Elniversity 
that is implemented in both Java and C++, but is no longer supported by its developers. 
To download or for more information about this tool please refer to this website: 
http://www.cs.bu.edu/brite/. GT-ITM is another topology generation tool that was 
developed at Georgia Tech and is freely available for download 
(http://www.cc.gatech.edu/projects/gtitm/). Inet is a more recent tool developed at the 
University of Michigan for generating Internet topologies. The latest version (3.0) was 
released in 2002 and can be downloaded at no charge from 
http://topology.eecs.umich.edu/inet/. Other tools and algorithms exist for generating 
topologies, but these are three popular tools that are available to anyone. 


c. Real-Time Visualization and Data Reduction 

The size of datasets has grown tremendously over the past ten years with 
increased processor speeds and hard-drive size. And despite these technological 
advancements, real-time visualization remains a difficult problem. In some cases, this 
problem can be overcome by data streaming which is characterized by processing 
independent subsets of the larger dataset. Streaming data is accomplished by breaking 
large files into smaller files and loading these files in series. The small files can be 
loaded in real time, while the single large file cannot. 
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Data reduction filters out data that is not relevant to visualization in order 
to make the size of the dataset manageable. Three traditional methods used to reduce the 
amount of network data to a manageable size are: 

• Aggregation which is used when large numbers of links or nodes are present 

• Averaging when dealing with large numbers of time periods 

• Threshold and exception reporting used to detecting changes (Becker et al, 1995) 
When using a data-reduction method, the possibility exists that important information 
may be obscured or lost during the reduction process. Instead of reducing the size of data 
sets and possibly loosing valuable information, research is being done to develop more 
efficient algorithms that reduce the computation time of popular force-directed layout 
algorithms used on large networks (Au et al, 2004). 

2. Available Network Visualization Tools 

Network visualization tools are continuously being produced and tweaked in 
order to adapt to changing needs and to keep pace with the advances and changes made in 
the network field. In the mid 90s, people at AT&T Bell Laboratories came up with 
SeeNet, which consists of three graphical tools for visualizing network data (Becker et al, 
1995). The example network used throughout the paper involves 110 nodes and over 
12,000 links. Instead of trying to create a single view that depicts all the necessary 
information at once, they chose to present the information in five separate views (Becket 
et al, 1995). One view is a network map showing the entire network, a time slider view 
for navigating through the time varying data, an interactive color scale view for 
manipulating link colors, a bird’s-eye view for a more detailed view of areas on interest, 
and a control panel view for other types of analysis and user controls. These views were 
all two-dimensional. A year later, they added a three-dimensional view for better 
geographic context (Cox et al, 1996). SeeNet is an application that was described in the 
previous section and is used for visualizing network data for communication networks. 

Another tool for network visualization is called VLNT (visualizing large network 
topologies). This tool is designed to assist network managers in analyzing and improving 
Internet routing topologies. Incorporated into this tool is a novel hybrid layout algorithm 
for visualizing large network topologies (Au et al, 2004). The algorithm uses the inverted 
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self-organizing map (ISOM) for initial layout, and then uses the Kamada-Kawai 
algorithm to refine and fine tune the layout. ISOM is stoohastieally based competitive 
learning algorithm that is highly versatile (can produce a 2D or 3D layout), consumes 
relatively few computational resources, and is not application specific (Meyer, 1998). 
The Kamada-Kawai algorithm is a force-directed layout algorithm that models the 
network as a set of springs and tries to find a layout that minimizes the energy in the 
springs (Au et al, 2004). By combining these two previous approaches to node placement 
and introducing a new termination criteria (edge-tension gradient) this new approach 
leverages overall layout structure of the ISOM method with the unclustering ability of the 
Kamada-Kawai method. The new termination criterion is “based on the ratio of the 
average edge length in the layout to the ideal edge length” (Au et al, 2004). The ideal 
edge length is calculated based on the dimensions of the display in order to keep the from 
being too large for the display. Termination is reached once this ratio falls below a 
specified threshold. The recommended thresholds were determined through empirical 
testing. 

The network animator (Nam) is a visualization tool that utilizes animated packet 
flow for taking in large amounts of information quickly and visually identifying patterns 
in communication to promote understanding of causality and interaction inside networks 
(Estrin et al, 2000). Nam has three different methods for generating the network 
topology. The first and most common method is an automatic layout algorithm based on 
a spring embedded model. The second method, used only for small topologies) is relative 
and allows the user to specify the relative directions of links (left, right, up down) and 
positions the nodes accordingly. The third method is wireless and associates a node with 
its physical location, but this method typically lacks explicit links. The animated packets 
appear as rectangles with arrows at the front to indicate direction of travel and the path is 
determined by trace events that indicate when a packet enters and leaves links and 
queues. 


C. CURRENT NETWORK ATTACK RESEARCH 

As society continues to move forward in the Information Age, computers are 


being integrated into more facets of everyday life than ever before. Additionally, these 
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systems are being linked to one another ereating new and complex networks. With all 
these systems and networks, information assurance and system security are critical areas 
of research. Within the information assurance and system security realms, the main 
research areas include modeling and understanding multi-stage attacks, developing 
detection models for novel attacks while having a low false alarm rate, real-time 
detection and analysis on high speed network traffic, and tracing the origins of attacks. 

1. Solutions 

a. Modeling and Understanding Multi-Stage Attacks 
A number of research efforts are focusing on classifying and categorizing 
the methods used to exploit vulnerabilities in systems during multi-stage network attacks 
(Tidwell et al, 2001). Multi-stage attacks are a type of blended attack with the ability to 
infiltrate protected systems by eluding threat detection systems (Dawkins and Hale, 
2004). Tidwell and his fellow researchers used parametric attack trees in conjunction 
with a system specification language to support vulnerability assessments and attack 
visualization that can be extended to provide real-time attack notification and monitoring 
services (Tidwell et al, 2001). 



Figure 7. Example attack tree from Bruce Schneier at Counterpane Systems. 

Attack trees represent attacks and countermeasures as a tree structure, where the root 
node is the goal of the attack and the leaf nodes are the attack methods (Schneier, 1999). 
Figure 7 shows a very basic example of the structure of an attack tree. More information 
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can be added to eaeh node sueh as a weight refleeting the probability of sueeess or with 
the cost associated with the node (Tidwell et at, 2001). 

Dawkins and Hale supplemented a network model with a eapabilities 
model to express the resourees and skills of the attaeker. The vulnerability model uses 
the two previous models to determine vulnerabilities, exposures, and exploits. An 
iterative attack chaining process identifles a series of possible attaek seenarios, whieh are 
used to eonstruet attack trees from the perspective of the attacker. Probability values are 
assigned to the given vulnerabilities during the analysis phase. These values help to 
identify the most probable avenues of attaek for multi-stage attaeks. 

b. Detection Models for Novel Attack Schemes 

IDSs are continually playing the cateh-up game to deteet the eontinuous 
and ever ehanging threats posed by eomputer attaekers. Attaekers are eontinually 
developing new methods to bring down or penetrate networks. New deteetion sehemes 
are being developed and tested in order to inerease the probability of deteeting novel 
attaeks while lowering the false alarm rate. Of eourse, the ideal seheme would have a 
100% deteetion rate with a 0% false alarm rate. Sueh a model does not exist and 
realistieally is near impossible to aehieve. Anomaly deteetion and pattern or signature 
reeognition are the two eommon deteetion sehemes implemented for intrusion deteetion. 
Pattern reeognition is efficient and accurate, but only useful in identifying known attaek 
patterns, while anomaly detection methods ean be used to identify novel attaeks. One 
reeent method utilizes Prineipal Component Analysis, a well-established teehnique for 
redueing dimensionality and multivariate analysis, to reduee the data attributes down to 
two or three dimensions (Labib and Vemuri, 2004). Analysis teehniques are 
subsequently applied to the linear eombinations of Prineipal Components to determine 
when attaeks have oeeurred. Another method expands upon existing intrusion detection 
work by generalizing the activity properties of data into a frequeney property, a duration 
property, and an ordering property (Ye et al, 2001). The method focuses statistieal 
methods including decision trees, Markov ehains, and Hotelling’s T test on analyzing 
these foeus areas. The study found that the frequeney property is essential for identifying 
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attacks, but when coupled with information from the ordering property, its identification 
power is increased (Ye et al, 2001). 


In a later study, researchers investigated the effects of building a long-term 
profile of normal activities on a machine in order to compare recent and current activities 
with the long-term profile to try to detect significant deviations (Ye et al, 2002). 
Detection is based on Hotelling’s test, which is able to detect both counter-relationship 
anomalies and mean-shift anomalies. 

Research has been done to visually combine information obtained from an 
intrusion detection monitoring environment with network traffic information. The 
information obtained can be used to identify bottlenecks, failures, and wasted resources 
on the network. The research conducted by Erbacher is geared towards simple two- 
dimensional visualization techniques for continuous online monitoring of the network by 
system administrators and network managers. The goal is to aid network managers’ 
“ability to asses the effectiveness of the network infrastructure and plan long range 
infrastructure management as well as deal with short term and immediate crisis, such as 
intrusions and misuses” (Erbacher, 2002). 


c. Real-Time Detection and Analysis 

Having good detection models is one thing, but being able to detect 
attacks while they are occurring and providing users with helpful information is another 
matter. In a recent study, ongoing attacks were visualized by mapping source IP 
addresses, destination IP addresses, and destination port numbers to a three-dimensional 
Cartesian space (Kim et al, 2004). These values are easily obtained from most Internet 
packets. Prom this plot, denial-of-service attacks, host scans, and port scans are easily 
seen. One short coming that was identified with this presentation method is that low 
intensity attacks and attacks occurring near dominant legitimate traffic are hard to 
identify from the three-dimensional plot. To over come this problem they implemented 
an original “pivoted movement” algorithm which tracks the three values of these packets 
and watches for instances where two of the coordinates remain fixed, while the third 
pivots around (Kim et al, 2004). 
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d. Tracing the Origins of Attacks 

The last main area of focus in network attacks is tracing the attack to its 
source. Often, attackers will forge their source IP address in packets in order to hide their 
identity. Proactive tracing is done before an attack is detected, while reactive tracing 
occurs after an attack is detected. Two proactive tracing methods are packet marking and 
messaging. Reactive tracing methods include hop-by-hop tracing, hop-by-hop tracing 
with an overlay network, IPsec authentication, and traffic pattern matching. A recently 
developed approach augments hop-by-hop tracing with “datalink-level identifiers such as 
Ethernet’s media access control (MAC) address, ATM’s virtual path identifier/virtual 
channel identifier (VPIA^CI), and frame relay’s datalink connection identifier (DLCI) to 
identify nodes in the packet’s path” (Baba and Matsuda, 2002). Because it is difficult for 
an attacker to forge the datalink-level identifiers of intermediate forwarding nodes, it is 
easier to trace packets back to their source using datalink-level identifiers. Because of 
the complexity of this issue and the fact that this information is not available within 
CyberCIEGE and not provided by intrusion detection systems, visualizing the origins of 
attacks is not presented in NTAV3D. 

2. Available Network Attack Visualization Tools 

A wide variety of intrusion detection systems are available for download on the 
web. Some are free like Snort, AirSnare, Prevx Home, WinPatrol, and System Safety 
Monitor, while others cost money like Process Guard, RegRun Gold, and Geek 
Superhero. 

NIVA is a network intrusion visualization application designed for interactive 
investigation and detection of structured attacks across time and space that utilizes three- 
dimensional displays (Nyarko et al, 2002). The application takes in output from an 
intrusion detector in simple ASCII or database format. This detection list is parsed 
according to the selected model. A node placement list is generated assigning locations 
for each node in three-dimensional space by employing either the IP-Space algorithm, the 
“spring technique,” or the “helix technique.” The IP-Space algorithm places components 
based on relationships gathered from the IP addresses of components. The “spring” 
technique assigns location based on the strength of a nodes connection to a central node. 
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while the “helix” technique assigns locations in helical pattern. Afterwards, a node-link 
map is created. The scene is rendered in OpenGL and the user then has the ability to 
manipulate both the displays and the data through the user interface. 



Figure 8. Typical NIVA Session (From Nyarko et al, 2002) 

The experiment specification and visualization toolkit (ESVT) was developed at 
Penn State University for use by experimenters conducting interactive experiments on 
network test beds (Li et al, 2006). It is comprised of a topology builder, a TCL script 
generator, and various visualization tools. Users have the choice of manually coding the 
topology themselves, or they can import topologies generated by Inet, GT-ITM, BRITE, 
or tiers topology generators (Li et al, 2006). ESVT is able to visualize traffic dump data 
and node status logs with the main method of visualization consisting of a time-series 
animation with adjustable time steps. A more in-depth visualization is available for 
viewing the data at a more refined level such as the number of UDP packets during a 
specific time period. This is achieved by selecting a link and defining the filter rules. 

LAN attacker is an application developed primarily through North Carolina A & 
T University, but also with help from Wesleyan College, to visualize the three major 
attacks on Local Area Networks: ARP Poisoning, Switch Port Stealing, and Mac 
Llooding (Baxley et al, 2006). The visualization provided includes a two-dimensional 
model of a simple local area network (about ten nodes) and simulates network traffic by 
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having virtual packets, containing the Mac address and IP address of both the sender and 
Target, that travel through the network model along the a virtual path represented by bold 
black lines (Baxley et al, 2006). 



Figure 9. LAN Attacker components (From Baxley et al, 2006). 

The figure above shows basic interface and network topology of the LAN Attacker 
application. During the attack phase, users ean select which method of attack will occur. 
Each of the attack methods is aecurately modeled for this simple configuration. Users are 
able to interact with the application by pausing the scenario at any point. This allows the 
user to examine the animated packets’ details, update ARP Cache Tables, and update the 
Port Mapping Tables. Additionally, text boxes appear as users’ mouse over the various 
devices in the scene. The application also features a short quiz upon completion of the 
scenario to test the comprehension of the user. 
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D. KEY TAKE AWAYS FROM CURRENT RESEARCH 

In order to create a successful visualization, one must display the information in a 
manner that allows users to easily understand the relationships and other statistics being 
displayed with as little confusion as possible. One useful method to reduce confusion 
levels is to only display the necessary information, and if possible, keep away from 
statically displaying numerical or textual information as they may take up valuable screen 
real estate. Color coding is one possible alternative to displaying numerical values when 
only relative estimations of values are necessary. 

Aside from the actual display itself, incorporating user interaction where possible 
is important because interaction between the user and the display increases the 
opportunities for the user to find a way to understand the information being displayed. 
This includes viewing the scene from multiple angles so that information occluded or 
partially obscured by one particular view is seen in a different view. Animation is a 
useful tool when trying to visualize network attacks. 
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III. NTAV3D TECHNOLOGY BACKGROUND AND DECISIONS 


A. INTRODUCTION 

Since the produet of the researeh of Chapter II is a working software applieation, 
it is therefore prudent to explain how the software was built, and why eertain 
development ehoiees were made. The intent is not to be a primer on the teehnologies 
diseussed below, but to explain how they relate to NTAV3D, and the reasoning behind 
why they were seleeted. The motivation of the following is to provide the reader a basie 
understanding of the underlying teehnologies that make up NTAV3D. Referenees are 
ineluded for further examination of eaeh teehnology. 

B. XJ3D 

I. Description 

As introdueed in Chapter I, Xj3D is the Java-based API for programmatieally 
implementing, and stand-alone browser for displaying, the X3D graphies format, and is 
developed by the Web3D eonsortium. (The Xj3D Projeet, April 2006) As sueh, 
NTAV3D utilizes both eomponents of Xj3D. The browser eomponent is eurrently 
implemented in a stand-alone applieation, whieh ean be launehed independently. 
However, the browser, and NTAV3D speeifieally, has the eapability to be embedded 
within a program as well. Additionally, the API eomponent, again known as the SAI or 
Seene Aeeess Interfaee, is what is used as libraries in NTAV3D’s Java eode to ereate and 
manipulate an X3D seene graph in a purely programmatie way. 

Xj3D is in a eontinual state of development. The most stable release is version 
1.0 dated 15 April 2006, but “snapshot” releases, whieh eontain new features and 
improvements, are eontinually added. For this, and reasons stated below, NTAV3D 
utilized the “bleeding edge” of the eodebase. Thus, the latest version of Xj3D 
implemented within NTAV3D is the “development snapshot” from 12 April 2007. More 
information on Xj3D ean be obtained from the projeet’s website at http://www.xj3d.org 
(aeeessed May 2007). 
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2. Decisions 

When choosing which software architecture to use to create a three dimensional 
scene, the authors were looking for a package that did not have a steep learning curve, 
and one that would be easy to integrate with CyberCIEGE first, and then network tools 
second. Due to the authors’ background in X3D via previous coursework, and the fact 
that both Xj3D and CyberCIEGE are implemented in Java, Xj3D became an attractive 
option. 

One example of an alternative to Xj3D was OpenSceneGraph, which is another 
three dimensional graphics package that is implemented with C++ and OpenGE. 
However, OpenSceneGraph has a fairly steep learning curve, and with little previous 
experience, the authors would have been required to learn the intricacies of programming 
with OpenGE, and C++, two programming constructs the authors were not as familiar 
with. Xj3D actually also implements an OpenGE renderer as the method of displaying 
the three dimensional scene. But, one of the benefits of the Xj3D libraries and 
implementation is that it handles all of the OpenGE setup “behind the scenes,” without 
requiring much work from the developers other than setting parameters for the browser 
component. Additionally, the authors were already familiar with the X3D system, and 
felt it would be a fairly easy transition to implementing X3D programmatically via the 
Xj3D SAL Eor further discussion of this experience, see Chapter VI, where an 
evaluation of Xj3D is offered. 

C. JAVA 

1. Description 

The main technology utilized to create NTAV3D was Java. Java is an open 
source, multi-platform programming language. Being open source means that Java’s 
program source code is freely available to be extended or enhanced without having to pay 
large licensing fees. This also means that programs created with Java have fewer 
restrictions on their ability to be redistributed. 

The application was compiled with the Java SE JDK (Java Development Kit) 
version six update one (otherwise known as Java 1.6). However, the application is 
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compliant with and will run on any Windows computer running Java version 1.5 or later. 
For further information about Java, and to obtain thee Java runtime needed to exeeute the 
applieation, one ean visit the Sun Java website at http://java.sun.eom/javase (aeeessed 
May 2007). 

Additionally, the primary IDE, or integrated development environment, ehosen 
was Eelipse, whieh is available from http://www.eolipse.org (aeeessed May 2007). 
However, sinoe the applieation is written purely in Java, any development environment 
oould be used, and in faot, some applieation testing and debugging was conduoted using 
the NetBeans IDE, available from http://www.netbeans.org (accessed May 2007). 

2. Decisions 

Java was the language of ohoioe for this thesis applieation, instead of, for 
example, C++, both because of the authors’ comfort level with the language, and due to 
the previously mentioned fact that the graphieal API of ohoioe, Xj3D, is implemented 
solely in Java. This choice of languages and APIs has many benefits. Eirst, both Java 
and Xj3D are open source and, as noted above, freely redistributable. This makes them 
quite viable for a Department of Defense program or for further expansion of oapabilities 
by an interested oommunity of developers later. Eor example, sinoe NTAV3D is Java- 
based, it oould oonoeivably be made as an applet, and distributed over the web, thus 
making network visualization quite portable (see Chapter V for more future work 
suggestions). Additionally, since the applieation is written in Java and with the Java- 
based libraries of Xj3D, it can run on almost any computer platform, be it Microsoft 
Windows, Apple OS X, or different variations of Einux. This is an exoiting feature, as it 
can be used on any of these maohines to visualize network activity. 

In terms of development environments, primarily, Eelipse was ehosen due to the 
comfort of the authors, and because it contains an excellent revision eontrol system, 
speeifically CVS (Coneurrent Versioning System). CVS is a system that allows 
programmers to work on application code simultaneously by storing the code in a 
“repository” on a central server. Authors “checkout” and “checkin” code as it is written, 
whieh allows everyone to be working off of the latest version, and not one that may have 
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become obsolete due to a colleagues editing. CVS is recommended for anyone who may 
be working on programming code with multiple authors as it facilities easier 
collaboration. 


D. XML 

1. Description 

XML stands for Extensible Markup Language, and is the main way NTAV3D 
receives data from outside programs, be it CyberCIEGE, or other network analysis tools. 
XML is a human-readable, non-proprietary file format that is most often used to 
exchange data between different computer programs or systems. XML is based on the 
concept of a tree based, hierarchical fide structure, where a tree of descriptive “tags” 
surround data. Additionally, XML schemas can be developed. These schemas are how 
XML becomes “extensible” in that the basic XML construct can be extended to create 
what amounts to a virtual language all its own, as different schemas can be developed to 
fit different needs. 

In the case of NTAV3D, a document type definition, or DTD, schema was 
developed to standardize how information from CyberCIEGE could be output as an XML 
file. It would be this DTD, and the CyberCIEGE XML-based output file that NTAV3D 
would load, parse, and use as input data to create the network visualization. Because this 
process is similar for all XML files, this is also how the program could be expanded to 
enhance intrusion detection systems (see Chapter V for more information on how 
NTAV3D XML processing works). 

To obtain more information about XML in general, one can visit the W3C web- 
standards body’s site at http://www.w3.org/XML (accessed May 2007). 

2. Decisions 

The decision to use XML as a kind of “middleware” for NTAV3D was made 
dude to the power of XML. Like Java, XML is platform independent, since it is nothing 
more than a text file. Additionally, XML is not a proprietary file format, so it is 
unencumbered by licensing restrictions and other restrictions on redistribution. XML, 
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due to its tree strueture, is also well suited for holding struetured data, sueh as network 
information, and as such is also fairly easy to parse. Also, through what are known as 
XSLT, or Extensible Stylesheet Language Transformations, other XML files can be 
converted to match the specifications of the NTAV3D XML parser, making it easier to 
import data from other sources besides CyberCIEGE. 
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IV. VISUALIZATION DECISIONS 


A. WHAT IS BEING VISUALIZED 

Before introdueing the deeisions and reasoning behind how elements are to be 
visualized, a brief diseussion of what is being visualized is neeessary. What are being 
visualized are attaeks on eomputer resourees and the assets stored on those resourees. To 
faeilitate this visualization the physieal network topology is presented. This topology 
eomes from the CyberCIEGE seenario being played, and with some added work, ean be 
extended to also inelude topologies deseribed by output from intrusion deteetion 
systems. 

I. What is a Component Compromise 

Component attaeks or compromises refer to flaws within the component 
protection mechanisms, or attacks on the component such as insertion of malicious 
software, or the physical theft of the component. Malicious software inserted into a 
component can originate from a variety of sources. In most cases within CyberCIEGE, 
the origin of an attack is not known. Information about the origin of some malicious 
software is potentially available within CyberCIEGE, but only in cases where a decision 
from the user, like not scanning emails for malicious content, results in a system 
infection. Even when it is the case that the origin is known, the information is not output 
to the visualization application. As a result, the goal was not to show how a component 
became compromised with malicious software, but that the component is compromised. 
Again, the focus of the application is on visualizing network topology, highlighting flaws 
or compromised components, and attacks on assets. 

The purpose of an intrusion detection systems is primarily to identify how a user’s 
system is compromised with malicious software and/or data designed to exploit known 
flaws. An intrusion detection system determines that an attack has occurred by observing 
traffic patterns and anomalous activities, such as port scanning. With most IDSs, the 
types of attacks that can be identified are limited to known attack patterns. Identifying 
the specific attack is difficult in some cases. With some additional research and work. 
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these vulnerabilities and eompromises ean be depleted using NTAV3D. The main 
obstaeles that eurrently prevent depletion of these vulnerabilities and compromises are 
discussed in section B of Chapter VI. 

2. What is an Asset Attack? 

An asset attack refers to attacks upon assets, which are contained within a 
component. Component compromises can facilitate asset attacks by providing an avenue 
by which an attacker can access the asset contained within the component. In some 
cases, the compromised component is not necessarily the component that contains the 
asset. For example, a firewall can be breached, leading to disclosure of an asset on some 
other component. Similarly, compromise of an outward facing web server can lead to the 
compromise of assets stored on the backend database systems or storage servers. An 
asset attack is launched by someone (an attacker) with the goal of obtaining the asset or 
altering it in some way that benefits the attacker. Integrity attacks and Secrecy attacks 
are the two types of asset attacks that are visualized. Availability attacks (e.g. a denial- 
of-service) are not represented as asset attacks because these attacks can be deduced by 
observing component compromises. 

a. Secrecy Attacks 

A secrecy attack results in the unauthorized disclosure of information. 
This can occur as the result of a lack of or failure to properly configure protection 
mechanisms. It can also occur as the result of component compromises described above, 
i.e., some combination of flaws, malicious software, or physical theft. In all cases, the 
flow of information is from the component containing the asset to the attacker. 

b. Integrity Attacks 

An integrity attack results in the unauthorized modification or destruction 
of information. These attacks occur in a manner similar to secrecy attacks described 
above. However, the specific modification that the attacker wishes to make to the asset 
may be encapsulated within malicious software inserted into a component that can access 
the asset at some later time. Therefore, since the tool does not depict the source of 
malicious software, the flow of information form the attacker to the asset is not always 
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depicted. The player might only see the flow of information from malicious software on 
some component to the asset. In this case, an attacker will not be displayed because this 
would illustrate the placement of malicious software, which is a facet of a component 
compromise that is not visualized. 

B. GEOMETRIC REPRESENTATIONS 

Because the structure of a network is represented well by a node link diagram, a 
big decision became what to use as nodes to represent the various network components. 
The logical solution was to represent the various components with actual models of the 
various components. This is by no means a new or novel idea. This method of 
representation allows the user to easily and correctly identify components within the 
visualization. 

I. Computers, Servers, and Routers 

All computers were modeled to resemble a typical computer tower. A monitor 
was not included in the model because tower representation was hypothesized to be 
sufficient enough for the user to correctly identify the model as a computer in the scene, 
although no user studies were done to confirm this hypothesis. A screen shot of the 
actual model developed to represent a computer is displayed in Figure 10 below. 



Figure 10. A screen shot of the front of the computer model 

Because a server is basically just a computer tower that has different software and 
in most cases lacks a graphical user interface, the same computer tower model was 
adapted to also represent servers. In order to reduce the confusion when trying to 

differentiate between servers and computers, without creating a separate model servers, 
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the aspect ratio of the server was altered significantly. The dimensions of the computer 
are 0.6 X 1.2 X 0.8 meters, while the dimensions for the server are 1X1X1 meters. 



Figure 11. A screen shot of the front of the server model 

Compared to Figure 10, the Figure 11 model appears tall and slender, while a sever 
model looks like a cube. In many cases in the real world a number servers are stacked 
atop one another inside a rack. This is also the case in some CyberCIEGE scenarios. In 
order to reduce ambiguity and allow CyberCIEGE users to distinguish individual servers 
from one another when stacked, black lines had to be added to the textures used on 
servers. 



Eigure 12. Multiple servers in a stacked configuration 

The figure above shows four severs stacked on top of one another. The black 
lines wrap all the way around the model such so that individual servers can be visually 
resolved within the server stack. These lines mark the border between servers. 

Routers are an essential component with the framework of a network. The routers 
were modeled after the average router that can be purchased from any retail vendor. This 
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model is easily identifiable when compared to computers and servers. The figure on the 
following page shows a side-by-side comparison of these three network components. 



Figure 13. A computer (left), router (middle), and server (right) 


2. Internet Cloud 

Physically modeling the Internet would be a challenge in and of itself. 
Additionally, a physical model of the Internet might not be correctly identified as such 
because people have not actually seen a physical representation of the Internet. A widely 
accepted and widely used method for abstractly representing the Internet is to use a 
cloud. A simple search on Google Images for “Internet Cloud” returns over 500,000 
results. A physical model of a cloud is used to represent the Internet within the 
visualization. A model of the Internet is necessary because at some point a connection is 
made to the Internet. Instead of having lines that connect to the Internet meeting at an 
arbitrary point in space, these lines will meet up within the Internet cloud model that is 
shown in the figure below. 



Figure 14. Internet Cloud model 
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3. Walls 

Within the visualization, walls were represented by paper-thin planes. These 
walls denote the zones in the seenario, whieh are the abstraetion, used to represent 
physieal seeurity in CyberCIEGE, and within the visualization, they provide the user with 
a visual spatial referenee frame. They were given a high level of transparency (.99 out of 
1.0) in order for geometry such as network lines and to be visible when looking down on 
the scene from above. Comparing Eigure 15 and Eigure 16 below illustrates why such a 
high level of transparency was needed. The level of transparency in Figure 15 is .99, 
compared to .85 in Figure 16. Also, the network links are clearly visible through the 
floor in Figure 15 while in Figure 16, the same lines are barely visible. 



Figure 15. Illustration of semitransparent walls with .99 transparency 



Figure 16. Illustration of transparent walls with .85 transparency 
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4. Network Links and Main Lines 

Figure 15 shows examples of both network main lines and network li nks . The 
network links represent eonneetions between eomponents and the network main lines. 
These connections are denoted by lines that have a width of a single pixel. In order to 
represent larger traffic flow rates present within network main lines, and to differentiate 
main lines from links, the main lines were model as large pipes. A radius of 0.3 meters 
was chosen in order to reduce the sensitivity of the touch-sensor associated with this 
geometry to a level where the user is able to effectively utilize the mouse-over capability. 
The difference in size between network main lines and network links is clear when 
comparing the three network main lines depicted along the bottom edge of Figure 15 with 
the network links spread throughout the remainder of the scene. Both network links and 
the main lines were color coded in order to differentiate between different networks 
present in the scene. 

5. Attacks: Component Compromises 

Component compromises refer to flaws or attacks that compromise a component 
itself, while asset attacks refer to attacks upon assets, which are contained within a 
component. CyberClEGE simulates a limited number of component compromises, and 
directly identifies the compromised component and the type of compromise. Within 
CyberClEGE, there are five types of component compromises: Trojan horse, virus, 
operating system flaw, trap door, and physical theft. Models were created to visually 
represent each of these compromising attacks. 


a. Trojan Horse 

The Trojan horse was modeled after an image of a Trojan horse. With the 
focus of this thesis (visualizing network structures and attacks occurring within these 
networks) in mind, the image to base the Trojan horse model upon was selected based on 
its simplicity and visual discernability. A simple model is less expensive to render than a 
complex model with a large number of vertices. The total number of vertices in the 
Trojan horse model is just under 250. Because a Trojan horse e is constructed from 
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wood, the model was given a light brown color. The resulting model displayed in Figure 
17 is discemable as a Trojan horse and quick to render. 



Figure 17. Trojan Horst model (left) and inspirational image of a Peramodel Trojan 
horse (3D paper model) from 

http://www.venus.dti.ne.jp/~kpd/jpg/world/trojan.jpg 


b. Virus 

A computer virus is merely lines of malicious code. Representing a virus 
in a three-dimensional world with a few lines of text may confuse a user. Instead, the 
virus modeled after a biological representation of a virus structure. Biologically, viruses 
take on many different structures. The image that provided inspiration and the resulting 
model are displayed in Figure 18. The virus model was given a red color to catch the 
attention of the user. 



Figure 18. Virus model (left) and the inspirational virus image from the Molecular 


Expressions 
March 2007. 


TM 


website at http://www.microscopy.fsu.edu/cells/virus.html 
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c. Trap Door 

A trap door is defined as “a mechanism embedded within a system that 
allows the normal access paths or access checks of a system to be bypassed. This often 
takes the form of a special password that is hard-coded into the software. It can also take 
the form of a special diagnostic interface” (Berg, 2005). The model created to represent 
this attack took the form of an animated wall. An opening appears in the center of the 
wall and remains open for a short period of time before returning to its original solid 
state. Figure 19 shows two trap door models, one model with the door closed and the 
other with the door open. Like the virus model, the trap door model was also given a red 
color to draw the attention of the user. 



Figure 19. Trap door model closed (left) and open (right) 
d. Operating System Flaw 

An operating system flaw can be thought of as a bug in the operating 
system code. This bug in the code is born when the operating system is written. Once a 
flaw is found in the code, it can then be exploited. With this notion of a bug in mind, the 
model for an operating system flaw was modeled after an insect. The inspirational insect 
is some sort of beetle. Just as with the trap door model and the virus model, the operating 
system model was colored red. The model is displayed in Figure 20 below. 



Figure 20. Screen shot of an operating system flaw model. 
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e. Physical Theft 

Physical theft is an easy eoneept for a person to visualize. One can 
visualize a person stealing a eomponent. Rather than having a person eome through the 
visualization and swipe a component, or make the eomponent randomly disappear, which 
may be confusing to the user, the decision was made to have a message displayed to the 
user informing him/her that a particular component was stolen. In case the location of the 
message does not clearly indicate which component was stolen, an arrow is included with 
the message and points directly at the stolen component. Figure 21 shows the message 
displayed to the user and its position in relation to the stolen eomponent. The text 
remains red for a period of time before briefly fading to white and then back to red. This 
brief change in color is meant to draw the attention of the user. 



Figure 21. Message displayed during a physical theft attack 

Each compromise is represented by a different geometric model. These models 
will appear just to the left of the eomponent that has been eompromised. The deeision to 
plaee the attack model to the left of the component was made beeause in many cases 
components might be staeked upon one another and if the model was placed above a 
component that has eomponents stacked atop it, the model would not be elearly visible. 
Placing the model just beside the component makes it visible in all cases except when 
components are placed side by side. It is an uncommon configuration to have 
components located side by side in CyberCIEGE scenarios. 

6. The Attacker 

Although an attacker is a physical person, representing the attacker with a model 
of a real person was not a logical option because not only would the model be 
complicated, but the model may distract a user from the remainder of the visualization. 
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After searching the Internet for intimidating figures that could be easily construed as such 
by a user, it was decided to create a partial person model. The model is basically just a 
person’s head and shoulders and was inspired by a police sketch image from New 
Zealand. The image served as both an inspiration for the actual geometry of the attacker 
icon and also serves as the texture used to color the geometry. The resulting textured 
geometry and the image that provided inspiration are displayed in Figure 22. 



Figure 22. Police sketch (right) of a suspect taken from identikit in Fairfax, New 

Zealand. This image applied to the attacker geometry as a texture (left). 

C. INTERACTION 

One of the key take-ways mentioned at the end of chapter two was importance of 
user interaction with a visualization. Users should have the ability to interact with the 
visualization in a variety of ways. The methods of interaction within NTAV3D include 
basic navigation capabilities, mouse-over capabilities, and a limited ability to modify the 
scene. 


I. Navigation Capabilities 

Navigating through a three-dimensional world can be tricky. Users can become 
easily disoriented if they are allowed to travel inside solid objects or if the navigation 
controls are difficult to use. The main navigation controls were modeled after the 
navigation controls that are currently in place in CyberCIEGE. One reason for doing this 
is that the navigation controls in place within CyberCIEGE are easy to use and afford the 
user the freedom to navigate anywhere they desire in the scene. The main reason for 
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making the navigation controls within the visualization application resemble the controls 
in CyberCIEGE is so that game players do not have to learn a separate set of controls to 
navigate within the visualization application. A list of the available “hot keys” and the 
corresponding actions produced by pressing these keys for both CyberCIEGE and 
NTAV3D is listed in Table 1. After observing the table, it should be clear that the 
majority of the main navigational controls utilized in CyberCIEGE are implemented in 
the visualization in the same or similar manner. 

The method for panning the camera side to side and forward and back in is one of 
the most notable differences. While the panning motion itself is essential, duplicating the 
CyberCIEGE implementation using off screen mouse movements would have required a 
large time investment. Investing a large amount of time just to exactly match an 
implementation style that the user is familiar with was not considered a good investment, 
when underlying feature could be easily replicated using input from the keyboard. Under 
this justification, it was decided to replicate the panning motion using selected hot keys. 

Because the camera does not automatically change its orientation while zooming 
or changing elevation, separate controls were added to allow the user to change the 
camera’s orientation. This allows the user to directly control the camera angle while 
viewing the scene from above or below. 

Toggling between sites using only one key was the last useful navigation feature 
in CyberCIEGE that was not implemented in NTAV3D in the same manner. Instead of 
using one key, two keys are used to switch between the main site and the remote site. An 
additional hot key was defined in order to move the view to where the entire scene (both 
main and remote site) are visible. 
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NTAV3D 


CyberCIEGE 

Key 

Action 

Key 

Action 

A 

Move camera down 

A 

Lower the camera 

a 

Move camera up 

a 

Raise the camera 

z 

Move camera forward (zoom in) 

z 

Zoom in 

Z 

Move camera backwards (zoom out) 

Z 

Zoom out 

r 

Rotate camera clockwise 

r 

Rotate camera clockwise 

t 

Rotate camera counterclockwise around 

t 

Rotate camera counterclockwise 

f 

Move camera right 

u 

Iterate through users 

g 

Move camera left 

s 

Iterate through support staff 

V 

Change camera’s orientation to look down 

m 

Iterate through computer 

components 

b 

Change camera’s orientation to look up 

d 

Iterate though network devices 

H 

Move camera to view entire scene and set 

the pivot point to the center of entire scene 

Tab / Shift 

Tab 

Iterate through simple camera 

positions 

h 

Move camera in front of main site and set 

the pivot point to the center of this site 

h 

Home (in current office) 

1 

Move camera in front of remote site and set 

the pivot point to the center of this site 

1 

Toggle between main office and 

remote site 

Ctrl 

Make walls appear 

Ctrl 

Slows panning 

Alt 

Make walls disappear 

Move cursor 

off screen 

Pans the camera in the direction of 

the cursor 


Table 1. List of “hot keys” for both the visualization and CyberCIEGE 


2. Mouse Over Capabilities 

All geometry displayed in the scene besides the network links and the walls have 
mouse over functionality built in. A game player can find out more information 
(component name, network name, or attack type) about these objects in the scene by 
placing the mouse over a piece of geometry. When the mouse is over a computer, router, 
or server, the name of the component will appear directly in front of the component in 
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large white letters. When the mouse is over a network main line, the name of the 
network pops up in front of the main line. Plaeing the mouse on an attack model display 
the name of the attack above the model. As soon as the mouse is moved off the 
component, the text will disappear again. The reason for text appearing and disappearing 
is to keep the scene as clutter free as possible. Having all the component names, network 
names, and attack types displayed on the screen at once would create a chaotic and 
confusing scene due to limited screen real estate and numerous elements vying for space. 
Messages would overlap forcing the user to decipher the alphabet soup displayed on the 
screen. This type of burden on the user would make it hard for the user to extract the 
information being presented. With the current mouse-over implementation, only one 
message will be displayed at any given moment because the mouse can only be over a 
single component. This eliminates the possibility of overlapping text and makes the 
message easy for the user to read. 

Attempting to place the mouse over a network link that has a width of one pixel 
would be extremely difficult and all necessary information (which component and which 
network the link is connected to is apparent from the scene). For these reasons, mouse- 
over functionality was not build into network link s . 

3. Scene Modification Capabilities 

The only modification of the scene that can be performed by the user is toggling 
the walls from visible to invisible and vice versa. This capability is necessary because 
the walls interfere with the mouse-over capability of components obscured by them. In 
the absence of walls, the user is able to navigate more freely and access the mouse-over 
features of components that were previously obscured by the walls. Turning the walls 
back on restores visual familiarity and the spatial reference frame provided by the walls’ 
presence. It should be noted that in order to turn the walls back on the user must press 
the Alt key twice in succession. The precise reason for this is not known, but this issue is 
explored in more depth during the section on evaluation of Xj3D in chapter six. 
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D. ATTACK ANIMATIONS 

Animation is used to both grab the user’s attention and to show data flow through 
the network. Animation is only used during an attaek. The animation used for 
eomponent attaeks is different from the animation used during an asset attack. 

1. Component Compromises 

As mentioned earlier in this chapter, component compromise models are placed 
just to the left of the component that has been compromised. Each of these models is 
animated so as to attract the attention of the user. The Trojan horse, virus, and operating 
system flaw models all have animated scales. This means that each model periodically 
gets larger then smaller. The trap door model looks like a solid wall for a few moments, 
and then a hole begins to open in the center of the wall. This hole remains open for a few 
second before closing, returning the wall back to its original solid form. The message in 
the physical attack changes color. It cycles between red and white, spending the majority 
of the time as red text. 

Although availability attacks are not explicitly represented in NTAV3D, users are 
able to determine when these attacks have occurred by observing the presence of 
component compromise models and the absence of an asset attack animation. 

2. Asset Attacks: Integrity vs. Secrecy 

In order to clearly represent the flow of traffic through the network during an 
asset attack, information in the form of a cone was animated to travel through the 
network. The animations for integrity attacks and secrecy attacks have a couple key 
differences. The main, and most noticeable, difference is in the direction of traffic flow. 
In an integrity attack information flows from the attacker to the asset. In order to convey 
the direction of flow a cone travels through the network to present the path taken by the 
information. Throughout the cone’s journey it say oriented such that the tip of the cone 
points in the direction of travel. In this way, the direction of travel can be ascertained 
from a static screen shot. During a secrecy attack, the flow is from the asset to the 
attacker. 
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Besides the direction of flow, the name of the asset attacked is displayed above 
the cone during a secrecy attack, while nothing is displayed during an integrity attack. 
The reason nothing is displayed during an integrity attack is because nothing is known 
about the information being sent by the attacker. By not directly informing the player 
which asset is being attacked during an integrity attack, the player must observe which 
component is being attack and reference the assets contained within the component to 
determine which asset is being compromised. When a component contains multiple 
assets, the component reference method fails. Determining how and where to present 
information about which asset is being attacked during an integrity attack is a topic for 
future work. 

One final way in which the user can distinguish between integrity and secrecy 
attacks is by the color of the cone. During a secrecy attack, the cone will be green, while 
the cone will appear red during an integrity attack. The choice in coloring was made 
solely to reinforce the fact that these two attacks are different. 

E. ROUTING NETWORK LINKS 

Because the positions of components like computers, routers, and servers is 
important and these positions are directly specified by CyberCIEGE, a unique routing 
scheme needed to be devised in order to route links between components and network 
main lines. 

As shown in Eigure 15, all network main lines are located at the front edge 
(largest z value) of the main site, but at different depths. The depth of a network main 
line is dependent on the order in which it is specified in the input file. The first one 
specified is at the shallowest depth below the floor, with the following network main 
lines at incrementally deeper depths. Placing all the network main lines at one edge of a 
site eliminated the possibility of a network link routing through a network main line as a 
link routes down to the corresponding network depth because none of the main lines will 
be directly under a component. 

In order to minimize ambiguity with connections between network links, a clear 
presentation scheme was developed in order to eliminate different colored lines crossing 
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(lines from different networks). To accomplish this task, a basic routing scheme was 
developed where links route out from a component in the x-direction, then down through 
the floor and over to the network main lines at the front of the site. The routing distance 
in the x-direction eliminates the crossing of network links as they route from components 
to network main lines by testing the “drop point” against already established network 
links. The drop point is the point at which the network link is dropped through the floor. 
If the drop point matches one from an existing link from a different network, then the 
drop point is incremented and tested again. This process is repeated until drop point is 
found that satisfies the test criterion. A clear presentation of routing can be found in 
Figure 23. 



Figure 23. Presentation of routing network links from an example scene viewed from 
two different angles. 


Figure 23 displays two different views of the same scene from different angles to 
showcase how network links on different networks (differentiated by colors) do not cross. 
This example scene has many components packed in a small area and without proper 
routing would be confusing to a game player due to crossing lines. Only network links of 
the same color, like the green lines routing out from the stacked servers, route down to 
their networks with the same drop point. This greatly reduces the amount of clutter in the 


47 














scene and emphasizes the intereonneetions between links on the same network. This 
method of presentation was not implemented to make all network connections from a 
particular network use the same drop point when routing from stacked components. If 
this were the case, the orange line eoming out of the top server would meet up with the 
orange lines on the other side of the stacked servers. This ineonsistent presentation is due 
to a eoding implementation, but with some additional work, the routing scheme within 
the NTAV3D application can be refined to include a single drop point for eaeh network 
connected to components in a stacked configuration. 
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V. APPLICATION IMPLEMENTATION 


A. JAVA APPLICATION ARCHITECTURE 

I. Xj3D (SAI) Scene Access Interface Implementation 

Three dimensional seenes are not something new, but ereating them by utilizing 
only the Java-based Scene Access Interface (SAI) of the Xj3D tool kit is. This is 
important because NTAV3D is one of the first applications solely developed utilizing the 
Xj3D SAI. A limited number of examples describing how to use the SAI can be found at 
the Xj3D website, and all of the examples rely on outside files for the actual creation of 
geometry. The sections to follow outline both the basics for how geometry, user 
interaction, and animations were actually created within NTAV3D and also explain some 
of the programming syntax involved. 

The basic scene graph structure that is utilized within the Xj3D’s SAI is the same 
as within X3D. A simplified scene for the creation of the transparent walls within 
NTAV3D can be found in Figure 24. All the nodes used within the scene are children of 
the Scene node. In addition to the basic parent-child relationships displayed in the scene 
graph. Figure 24 also notes which fields are important within each node, and displays a 
routing diagram that is denoted by the hashed lines. The various components of the scene 
graph presented in Figure 24 will be explained over the next three subsections. 
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point 


Figure 24. A simplified seene graph for ereating walls within NTAV3D that notes 
important fields for nodes and includes a routing diagram 


a. Geometries Used in NTAV3D 

As mentioned in Chapter IV, physical objects within NTAV3D are 
represented by models resembling these objects. The majority of the geometry visible in 
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NTAV3D was created using indexed face sets and indexed line sets. In addition to these 
two types of geometry, cones and extrusions were used. 

(1) Xj3D Geometries Explained 

Indexed faee sets are one method for ereating geometry. They are 
eomprised of a set of polygonal faces. The first step in creating an indexed faee set is to 
define the list of vertiees that describe the strueture of the object in the “points” field of 
the Coordinate node attached as a child. The next step is to delineate which vertices 
make up whieh faee in the “coordindex” field of the IndexedFaceSet node. This is 
aceomplished by refereneing the indiees of vertices in the list. A single vertex can be a 
part of several polygonal faces. This framework for ereating objeets is effieient by way 
of reusing vertices, and versatile in that any solid object can be modeled. Indexed face 
sets were used to model the walls, computers, routers, servers, the Internet cloud, all the 
component compromise models (except physical theft), and the attacker ieon in 
NTAV3D. Figure 24 illustrates the scene graph strueture involved in creating an indexed 
faee set. 

Indexed line sets are very similar to indexed face sets. They too 
are comprised of a list of vertiees, but instead of a list that ereates polygonal faces, an 
indexed line set has a list that specifies the order in whieh vertices are applied to create a 
segmented line. Indexed lines sets were used to ereate the various network links seen 
throughout seenes in NTAV3D. These lines have a unique property of always having a 
thickness of one pixel regardless of how elose or distant the line is within the scene. 
Replaeing the IndexedFaceSet node with an IndexedLineSet node is the only ehange to 
the scene graph in Figure 24 needed to ereate an indexed line set. 

Cones are one of the predefined simple geometries available in 
Xj3D. The only information neeessary to create a cone is a height and a radius. Within 
NTAV3D, eones were used to represent data. One only need substitute the 
IndexedFaceSet node and its ehildren in Figure 24 with a Cone node in order to create a 
cone. 
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Extrusions are the last method used to create geometry within 
NTAV3D. An extrusion is defined by a two-dimensional cross section and a spine. The 
cross section defines the prominent structure of the object. An extrusion is created by 
repeating the cross-section along the vertices defined in the spine. The spine can also be 
thought of as a set of controls points for controlling the smoothness between cross- 
sectional slices. Extrusions were used in NTAV3D to model the network main lines. 
The cross-section was a circle, and the spine consisted of a beginning point and an end 
point. This created a three-dimensional pipe. An extra point in the spine was necessary 
in the case when a network main line connected to the Internet cloud. This created a 
smooth pipe with a single bend in it as illustrated by the red pipe in Eigure 29 (page 79). 
Substituting the IndexedFaceSet node Eigure 24 with an Extrusion node is all that is 
required to create an extrusion. 

(2) Examining the Java Syntax 

Understanding the relationships within the scene graph in Eigure 
24 and knowing which node fields are important make coding easier. This section 
outlines how the walls were created within NTAV3D by examining code snippets from 
the WallCreator class, which can be found in its entirety in Appendix B. 

The pattern for creating any node within the scene is shown in the 
first line of the code snippet below. 

X3DNode tr = scene . createNode { "Transform" ) ; 

MFNode tran_children = (MFNode) tr.getFieldC'children"); 

tran_children . clear () ; 

In the first line, a Transform node is created and added to the scene 
by providing the createNode() method with the string “Transform.” A list of other nodes 
used within NTAV3D can be found in Appendix A. Because a node is created by 
specifying the name of the node via a string, the spelling must be exact or a run-time 
error will occur. A Transform node is a type of grouping node, so it was necessary to be 
able to add children to this node. The second and third lines of code create access to the 
“children” field and clear this field in preparation for adding children. The next step to 
create the actual geometry. 
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All geometry nodes are ereated as a child of separate Shape nodes. 

Creating the Shape, IndexedFaceSet, and Coordinate nodes is accomplished in the same 

manner that the Transform node was created. 

X3DNode shape = scene .createNode ( "Shape" ) ; 

X3DNode box = scene .createNode (" IndexedFaceSet ") ; 

X3DNode coordinate = scene . createNode ( "Coordinate ") ; 

The method for defining the vertices that comprise the indexed 
face set is not as straightforward as adding the node. A special relationship is formed 
between the parent node {IndexedFaceSet) and the child node (Coordinate) using a 
SFNode. Through this relationship, the values set in the “points” field of the Coordinate 
node are assigned to the “coord” field of the IndexedFaceSet node. 

SFNode line_coord = (SFNode) (box .getField ( "coord" )) ; 

MFVec3f point_value = (MFVec3f) {coordinate . getField ( "point ")) ; 
point_value .setValue {8, new float [] { this . cornerl [ 0 ] , -1, 

this ,cornerl [ 1 ] , . . . this . cornerl [0], 3, this . corner2 [ 1 ] , }); 

line_coord.setValue (coordinate) ; 

Setting the value of the “coordindex” field of the IndexedFaceSet 

node is much more straightforward since this field exists within the IndexedFaceSet 

node. This field references the vertices defined in the “points” field of the Coordinate 

node by using indices. Individual polygon faces are separated by values of negative one. 

Because some browsers implement indexed face sets in different manners it is a good 

practice to completely close faces by ending with the same point that began the face (first 

specified face is 8, 9, 5, 4, 8, -i) . 

MFInt32 coord_index = (MFInt32) (box.getFieldC'coordIndex")); 
coord_index .setValue (30, uew iut[] { 8, 9, 5, 4, 8, -1, 9, 10, 6, 

5, 9, -1, 10, 11, 7, 6, 10, -1, 11, 8, 4, 7, 11, -1, 4, 7, 6, 5, 
4, -1, }); 

Once the geometry is defined, it must be added to the scene. This 
is accomplished using another special relationship node to assign the IndexedFaceSet 
node as the “geometry” field value for the Shape node. The Shape node is then appended 
as a child of the Transform node. The Transform node becomes a child of the Switch 
node, which is then added to the scene. 

SFNode shape_geometry = (SFNode) (shape . getField ( "geometry ")) ; 

shape_geometry.setValue(box) ; 

tran_children.append(shape) ; 

switch_children.append(tr) ; 

scene.addRootNode(switchNode) ; 
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Both the direct and indirect methods for adding nodes to the scene 
are illustrated in the previous code snippet. The direct method explicitly adds the node to 
the scene. The indirect method involves appending nodes as children of nodes that are 
directly added to the scene. 

b. Texturing 

(1) What is a Texture and What is it Used for? 

A texture is an image that is put on an object to color it. Texturing 
is done on a per fragment basis, whereas assigning color is done on a per vertex basis. 
Using a texture allows one to explicitly assign colors per fragment using texture 
coordinates (texels) as opposed to interpolating color values between vertices. Similar 
results could be achieve by manually assigning colors to vertices, but a much larger 
number of vertices for the same geometry is required. Texturing is an extremely 
common and widely used method in the gaming industry (both console and computer 
games). 


(2) How are Textures Placed on Objects? 

The example code that follows is taken from the Attackericon 
class. The example code in this subsection shows how the rectangular image of the 
attacker in Figure 22 (page 41) was mapped to the oddly shaped geometry in the figure. 
An Appearance node and an ImageTexture node do the bulk of the work in assigning a 
texture to an object. 

XSDNode appearance = scene.createNode { "Appearance" ); 

X3DNode image_texture = scene .createNode ( "ImageTexture" ); 

As with the creation of an indexed face set, special relationships 
are utilized while assigning values from a child node to a parent node. The actual name 
and location of the image file used as the texture is specified in the “url” field of the 
ImageTexture node. 

SFNode shape_appearance = (SFNode) (shape .getField ( "appearance" )) ; 

SFNode appear_texture = (SFNode) (appearance .getField ( "texture" )) ; 

MFString textureURL = (MFString) (image_texture.getField("url")); 

textureURL .setValue (1, new String [] { "images.jpg" }); 

appear_texture .setValue (image_texture) ; 
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In the forth line the file name is speeified in the setValue() method 
by using a string array and its length. A string array is used so that multiple paths to the 
same image file ean be specified, and if the first path fails, the next path in the array list 
will be tried. This provides alternative URLs for redundancy when referencing images 
on the web. 


This next snippet of code shows the steps necessary to map a 
rectangular image to an irregular polygonal face. The “texCoordIndex” field of the 
IndexedFaceSet node is set in the same manner that the “coordindex” field is set. 

MFInt32 texCoord_index = (MFInt32) 

(attacker . getField { "texCoordIndex" ) ) ; 
texCoord_index. setValue (textCoordIndex.length, textCoordIndex); 

As seen in Figure 24, a Texture Coordinate node is created as a 
child of the IndexedFaceSet node. Texels are defined in the “points” field of the 
TextureCoordinate node in much the same way that vertices are defined in a Coordinate 
node. Using the special parent-child relationship node, these texels are assigned back to 
the “texCoord” field of the IndexedFaceSet node. Once these values are assigned back to 
this field, they can be mapped to vertices on the indexed face set. 

X3DNode textureCoord = scene .createNode { "TextureCoordinate" ); 

SFNode text_coord = (SFNode) (attacker .getField ( "texCoord" )) ; 
MFVec2f textCoord_value = (MFVec2f) 

(textureCoord. getField ( "point" ) ) ; 
textCoord_value . setValue (textureCoordinates . length / 2, 
textureCoordinates); 
text_coord. setValue (textureCoord) ; 

c. User Interaction 

(1) Types of User Interaction 

The two avenues by which the user can interact with scenes 
created by NTAV3D are the keyboard and the mouse. As described in Chapter IV, the 
keyboard is used to move around within the scene and to turn walls on and off. The 
mouse is used to uncover additional information about objects (i.e. the components name, 
the name of the zone, or the name of a network) by placing the mouse over a given 
component. 
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(2) Creating Interaction with the Xj3D SAI 

A Switch node is a type of grouping node that renders one or none 
of its renderable children. Which child is rendered is controlled by the field 
“whichChoice,” and by default, it is set to the first child. In the following code snippet, a 
Switch node is created and set to render its first child. No children are rendered by setting 
the value of the field “whichChoice” to minus one. 

XSDNode switchNode = scene . createNode {" Switch" ) ; 

MFNode switch_children = (MFNode) switchNode.getFieldC'children"); 
switch_children . clear () ; 

SFInt32 whichChoice = (SFInt32) 
switchNode .getField { "whichChoice" ) ; 
whichChoice . setValue ( 0 ) ; 

The first step in implementing the mouse-over feature to geometry 
in the scene was to add a TouchSensor node. Touch sensors receive input from the 
mouse. They know where the mouse pointer is located and whether a click is registered. 
Adding a TouchSensor node is the same as adding any other node, but it needs to be 
added to the scene graph such that it is at or above the level of the desired geometry. In 
the code snippet below, the TouchSensor is added to the Transform node as a child, 
which means that it will be associated with any geometry nodes that are children of that 
Transform node. 

X3DNode touchSensor = (X3DNode) scene. createNode ( "TouchSensor") ; 
scene . addRootNode (touchSensor) ; 
tran_children .append (touchSensor) ; 

Once a touch sensor is linked to geometry, it is able to determine 

when the cursor is placed over or clicked upon a geometry linked to it. The next step is 

to introduce the necessary logic components and route information to the necessary 

nodes. Only one BooleanFilter node is necessary to create the mouse-over feature, while 

two are needed to toggle the walls on and off. A BooleanFilter node takes in a Boolean 

value and outputs a Boolean value. The filtering aspect of this node comes from sending 

out a value only when specific Boolean input is received, or the Boolean input can be 

negated and sent out. The following code snippet shows the creation and addition of a 

BooleanFilter node to the scene. 

X3DNode bf3 = scene .createNode ( "BooleanFilter" ) ; 
scene . addRootNode (bf 3) ; 
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Once the BooleanFilter is in plaee, a series of IntegerTrigger 
nodes is necessary to convert Boolean inputs into integer outputs. The “integerKey” field 
is where the desired output integer value is speeified. Only one integer value ean be 
speeified for eaeh IntegerTrigger node. An IntegerTrigger node only outputs the integer 
value when a Boolean true event is reeeived. Two IntegerTrigger nodes are ereated and 
assigned different output values before being added to the seene in the following code 
snippet. 

X3DNode triggerTextOn = scene. createNode {"IntegerTrigger") ; 

SFInt32 integerKeyOnText = (SFInt32) triggerTextOn 
. getField {" integerKey " ) ; 
integerKeyOnText. setValue ( 0 ) ; 
scene . addRootNode (triggerTextOn) ; 

X3DNode triggerTextOff = scene. createNode {"IntegerTrigger") ; 

SFInt32 integerKeyOffText = (SFInt32) triggerTextOff 
.getField ( "integerKey" ) ; 
integerKeyOffText .setValue (-1) ; 
scene .addRootNode (triggerTextOf f) ; 

The last step is to route information from one node to another to 
ereate the desired interaetion. Route nodes are used to send information from one node to 
another. A route sends values from an output field in the souree node to an input field in 
the destination node. Routes are depicted in Figure 24 by hashed red lines with a single 
arrow head eonveying which node is the source and whieh is the destination. Route 
nodes are a vital eomponent of any interaction or animation that occurs using X3D, 
Xj3D, or VRML97. 

scene. addRoute (touchSensor, "isOver", bf3, "set_boolean"); 
scene. addRoute (bf3, "inputTrue", triggerTextOn, "set_boolean"); 
scene. addRoute (bf3, "inputFalse" , triggerTextOff, "set_boolean"); 
scene. addRoute (triggerTextOn, "triggerValue" , switchNodeText, 

"set_whichChoice" ); 

scene .addRoute (triggerTextOff, "triggerValue" , switchNodeText, 

"set_whichChoice" ); 

Matching field types is vital during routing proeess in order for 
things to work. Boolean values must be routed to Boolean fields and integer values must 
be routed to integer fields. 

The BooleanFilter is the intermediary for Boolean values between 
the TouchSensor and the IntegerTtriggers. Without the BooleanFilter, Boolean values 
would be routed from the TouchSensor to both IntegerTriggers at the same time resulting 
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in conflicting commands. Both IntegerTriggers would attempt to send integer values at 
the same time, and the last integer received would be the one to influence which node 
would be rendered by the Switch node. By having the IntegerTriggers receive values 
from the Boolean filter, only one IntegerTrigger receives a value during an event and 
conflicts are avoided while setting the rendering choice of switch node. 


d. Animation 

(1) Nodes Vital to Animation 

The three nodes that make animation possible are the TimeSensor, 
an Interpolator, and Route nodes. The TimeSensor node acts as a clock. Fields within 
the TimeSensor node allow one to specify whether the animation will be looped, and the 
duration of the animation. A TimeSensor also keeps track of the fraction of time that has 
elapsed during the animation. This faction is useful for the Interpolator node. The 
fraction of time elapsed tells the Interpolator node how much to interpolate the values 
within the Interpolator node. The Route nodes are used to connect the TimeSensor to the 
Interpolator, and the Interpolator to the component being animated. The lines of code to 
follow in the next subsection were taken from the PhysicalAttack class. The entire class 
can be found in Appendix B. 


(2) How to Create Animation using Xj3D SAI 

The first step to creating an animation is to create the TimeSensor. 

Once the TimeSensor is created its fields can be modified to enable a looped animation 

and the cycle interval can be set. 

XSDNode timeSensor = scene .createNode { "TimeSensor" ); 

SFBool loop = (SFBool) timeSensor.getFieldC'loop"); 
loop .setValue (true) ; 

SFTime cycleinterval = (SFTime) 
timeSensor .getField ( "cycleinterval" ) ; 
cycleinterval. setValue (2.0) ; 
scene . addRootNode (timeSensor) ; 

The next element necessary to create an animation is to create the 

Interpolator node or nodes. The two fields of importance within an Interpolator node are 

“keys” and “keyValues.” The first is a list of instants in time specified by floating point 
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values between 1.0 and 0.0. The second field lists the state for each instant in time listed 
in the “keys” field. The code snippet below shows a Positioninterpolator node being 
created and the “keys” and “keyValues” fields being set. 

float[] keys = { 0, .25f, .75f, 1 }; 

float [] keyValues = { 1, 1, 1, 1, 0, 0, 1, 0, 0, 1, 1, 1 }; 

X3DNode pi = scene .createNode ( "Positioninterpolator" ) ; 

MFFloat key = (MFFloat) pi .getField ( "key" ) ; 

key .setValue (keys . length, keys) ; 

MFVec3f keyValue = (MFVec3f) pi.getFieldC'keyValue"); 

keyValue . setValue ( (keyValues . length) / 3, keyValues); 

scene .addRootNode (pi) ; 

As with user interactions, the last step is to connect Route nodes 
between source node fields and destination node fields. The routing pattern shown in the 
code snippet below is the pattern used when employing an Interpolator node. 

scene. addRoute (timeSensor, "fraction_changed" , pi, 

"set_fraction" ); 

scene. addRoute (pi, "value_changed" , material2, "diffuseColor" ); 


2. Java Class Structure 

The basic programmatic flow of the application is depicted in Figure 25 on the 
following page. This diagram depicts the steps of execution each time NTAV3D is 
launched, and allows one to gain a better understanding of how the different parts of 
NTAVSD’s code interact with each other. For a full UML (Unified Modeling Language) 
class diagram, which breaks down all of the Java classes and their elements, see 
Appendix C. 
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B. XML PROCESSING 

1. XML in NTAV3D 

As mentioned in Chapter III, XML was used to exehange data between outside 
applications and NTAV3D. In this way, XML functions as a kind of “middleware” to the 
application. The following sections will serve to describe how XML is utilized in 
NTAV3D. The structure of the XML fde will be discussed, including what data was 
included and why. Then, the way NTAV3D actually processes the XML file will be 
described. Knowledge of how NTAV3D handles XML is helpful to understand how the 
program processes data, and will also facilitate a better understanding of how it can use 
data from other programs (which will be addressed in the next section). 

2. File Structure 

To understand the structure of the XML file NTAV3D receives from 
CyberCIEGE, Appendix D contains the CyberCIEGE document type definition, which 
specifies the format of the XML file output from CyberCIEGE. Appendix D also 
contains an example XME file that was actually output from CyberCIEGE. This is the 
same example scene depicted in Eigure 29. The CyberCIEGE XML file’s structure is 
one that starts at a higher level of detail about the networks, and then continually drills 
down to include more details about the networks and their components. The file starts 
with high level data, such as which networks are currently involved in the game, and 
details about them such as their name, and the color that they are mapped to in the game. 
NTAV3D maintains this color mapping when displaying networks in an effort to help 
player orientation. The next part of the XML file includes definitions of each network 
zone (which corresponds to the previously mentioned transparent walls displayed), and 
the components within each zone. Each component has such attributes as the type of 
component, the name given in the game, the networks the component is connected to, and 
any data assets that may exist on the device. An example of this data in XML is shown 
below. 

<network> 

<networkName>Offsite LAN</networkName> 

<color>0xFFFFFF00</color> 

</network> 

<mainSite> 
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<zoneName>Entire Office</zoneName> 

<upperLeft><x>33</x><z>49</z></upperLeft> 

<lowerRight><x>56</x><z>3 l</z></lowerRight> 

<component> 

<componentName>Joe_ws</componentName> 

<componentBase>Blato Desktop Select</componentBase> 

<location><x>3 5</x><y> 1 </y><z>3 6</z></location> 
<networkName>leased</networkName> 

<networkN ame>Lan 1 </networkName> 

<assetName>Plans</assetName> 

</component>. . . 

</mainSite> 

Finally, the XML file can contain information on the kind of network attack 
occurring on or over the network. This provides NTAV3D with a way of visualizing the 
attacks that occur in CyberCIEGE. This information will only be included in the file at 
the time of an attack. See the next section for a discussion of this attack data. 


3. CyberCIEGE XML Information 
a. Topology Data 

During the course of NTAV3D development, changes were made 
continually to the structure of the CyberCIEGE Document Type Definition (DTD) so that 
information provided to NTAV3D is more useful. Eor example, to show the network 
topology and general office structure, the physical location of components, and office 
“walls,” or zones, was needed. Eor easier topology and data display, the names of each 
component and the names of the networks it is connected to was needed. Therefore, for 
each zone and component, location data was added to the XML file specification. As 
will be discussed later, providing a physical location for components in a real network is 
quite difficult, so including location data in the CyberCIEGE file helped to eliminate a 
layer of complexity. CyberCIEGE already was storing location data from the “office 
view”, it only made sense to provide that information to NTAV3D. Another benefit of 
this is that it allowed the mappings of where objects were located in the “office view” to 
be similar in NTAV3D. Again, this helps aid gameplayer orientation. 
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b. Attack Data 

Another crucial area of data that was needed from CyberCIEGE was that 
relating to network attacks. This is vital for NTAV3D, as it allows it to visualize the 
attacks that occur in the game, as opposed to the game’s current generic movie clips. 
After conducting the research discussed previously, the details of a network attack to 
include in the CyberCIEGE XML file was decided. Eirst, NTAV3D has to know which 
network component or components were compromised. Next, the specific asset that was 
on the components must be known. Once this data is outlined, “segment” data is needed 
in order to show the information flow resulting from the attack. This information will 
determine the route the attack followed by providing the networks and networking 
components that the attack passed through. Once these segments are known, NTAV3D 
then uses an algorithm to determine the specific path of the attack, and thereby show an 
animated cone to represent data flow. Einally, CyberCIEGE outputs the type of attack 
occurring (secrecy, integrity, Trojan horse etc.), and also the type of attacker. This 
information allows NTAV3D to display its icons specific to each attack, so that the 
gameplayer is given context of which kind of attack is occurring. An example of this 
data in XML format is shown below. 

<attack> 

<assetName>Basic Research</assetName> 

<policy>Integrity</policy> 

<segment><Network>Intemal LANl</Network><componentName>Bit 
F lipper_3 </ componentNamex/ segment> 

<segment><Network>Intemal LAN2</Network><componentName>Five Inches of 

Asbestos_4</componentName></segment> 

<segment><Network>Intemet</Network></segment> 

<attacker>Attacker</attacker> 

</attack> 

By parsing this data, NTAV3D has the information needed to depict a 
network attack. Eigure 26 on the following page shows a screenshot of a miming 
example of a network attack in NTAV3D. 
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Figure 26. Screenshot of a running example of a network attack in NTAV3D 


Note the attacker icon in the figure, as well as the cone to depict data flow 
seen traveling along the red network (in this image it is directly below the foremost 
transparent zone wall and moving left). Also, while CyberCIEGE does not currently 
export data about component compromises or asset attacks, the structure and data content 
will be similar to that above, and it is expected NTAV3D can display them. 


4. XML System Implementation 

At the time NTAV3D is launched, it looks for an XME file, whose file system 
path is specified at run-time as a startup parameter. Once the file is located, the Apache 
Xerces XML parser is utilized to parse the file. Some of the code behind this is available 
as an excerpt (for brevity) in Appendix B. The parser then searches for specific XML 
nodes specified in the Java code, and creates an internal list of the node, and the sub¬ 
elements contained in it. Eor example, it will look for all “component” nodes, and then 
store a list of the “componentName,” componentBase,” etc. for each node. Then, the 
NTAV3D code loops through each list, extracting information as it goes, or taking 
actions in the Xj3D scene, such as creating a new server object, or constructing walls. 
An example of this kind of action is in the code below 

Element netNameElmnt = (Element) netFstNode; 

NodeList netNmElmntLst = netNameElmnt 

.getElementsByTagName ( "networkName" ); 
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Element netNmElmnt = (Element) netNmElmntLst. item ( 0 ); 

NodeList netName = netNmElmnt. getChildNodes(); 
networkStorage. getNetworkArrEl (holdnet). setNetworkName( 

(netName. item( 0 )).getNodeValue()); 

This code is going through the already defined “Network” list and looking for the 
element known as “networkName.” When it finds this, it gets the value and stores it 
within the NTAV3D array (a Java programming structure for holding data) known as 
“networkStorage.” This process is then continued for all of the nodes in the XML file. 


C. NETWORK TOOL INTERACTION 

1. Why Work With Network Tools? 

Some intrusion detection systems, such as Snort, can detect attacks automatically 
and in real-time. Therefore, a valid question is why bother displaying a network attack to 
a human operator at all? Why not just automatically remove the offending packets from 
the network and be done? By providing a visual depiction of the attack, and especially 
one that is interactive and in three dimensions, the objective is to provide the network 
security professional with increased situational awareness (the need for studies to prove 
this situational awareness enhancement is addressed in Chapter VI). By being able to 
“see” the attack happening, a somewhat abstract idea of unseen electronic attack can be 
put into a more usable context, hopefully one that the security operator can use to his or 
her advantage to repel future attacks. 

2. Tool Output 

However, allowing NTAV3D to work with other network analyzers and intrusion 
detection systems, such as the aforementioned Wireshark or Snort, is a much more 
complicated problem than that posed by CyberCIEGE. This is mainly due the fact that 
these network tools are showing the information from a “real” network, instead of the 
“scripted” one shown in CyberCIEGE. Whereas CyberCIEGE can tell NTAV3D where 
certain components etc. are located, to discover the physical location of a network node 
using a program like Wireshark or Snort can be extremely difficult. 

Indeed, network topology generation could be a completely separate and 
independent thesis topic. Along these lines, there are additional differences between the 
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kinds of data CyberCIEGE can provide, and that which a network tool can. Table 2 
below shows a comparison of the kinds of data NTAV3D displays of a CyberCIEGE 
“office”, and the data network tools can provide. The table also shows the difficulty (as 
rated by the authors) that it would take to obtain the data from a network tool. In some 
cases, such as office zone names, a network tool would not normally provide that kind of 
information, but it is included in the table to show the details included by CyberCIEGE 
that would probably not be able to be included via a network tool. 


Data Type 

CyberCIEGE 

Network Tool 
(Wireshark 
Snort, etc.) 

Difficulty of Obtaining 
Data Erom Network Tool 

Physical Office Zone Names & 

Locations 

X 

- 

6 

Network topology 

X 

X (with topology 

generator) 

5 

Network attack origin 

X 

- 

5 

Specific asset compromised 

X 

X 

5 

Path of network attack 

X 

X 

5 

Network Attack Type (Trojan 

horse, etc.) 

X 

X 

4 

Assets stored on component 

X 

X 

4 

Network Names 

X 

X 

4 

Detect live network attacks 

- 

X 

3 

Networks component belongs 

to 

X 

X 

3 

Component types (server, 

computer, etc.) 

X 

X 

3 

Component names 

X 

X 

2 

Log real network data packets 

in real-time 

- 

X 

1 

Table 2. Table comparing CyberCIEGl 

E data to network tool data, and the ease of 


obtaining said data from a network tool. Difficulty is from 1-6, with 1 being easy, 5 
being extremely difficult, 3 being moderately difficult, and 6 being basically impossible 
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As can be seen, some of the most diffieult aspeets of using a network tool for 
network visualization involve extracting network topology, and determining data flow. 
NTAV3D eannot solve these problems, nor is it meant to. NTAV3D has the capability to 
visualize this information, but aetually deriving this data is outside the seope of this 
thesis. 

Representing network attaeks in almost “real-time” is quite a ehallenging aspeet 
of network security. Snort, as an example, ean log paekets of network data, and attempt 
to alert network seeurity professionals of possible intrusion attempts. Using the 
methodology detailed in the next seetion, it ean, with future work, be possible to 
represent this data in NTAV3D, thus providing a visual eontext for how data is flowing, 
and nodes that are eompromised, whieh would be quite useful. For example, if Snort 
were to deteet a Trojan horse program trying to send unauthorized data, NTAV3D eould 
display exaetly where that node is, and what internal networks the data is traveling 
through. Again, however, NTAV3D is only meant to visualize sueh data, not discover 
and derive it itself. The next section explains how NTAV3D can be utilized in sueh a 
role to provide this type of visualization. 

3. Proposed NTAV3D Methodology 
a. Data Manipulation 

In order to provide visualization eapabilities to network protoeol analyzers 
or intrusion deteetion software, the thesis applieation eould employ its already existing 
XML parser. This will require the help of outside tools however; as again, NTAV3D is 
not a stand-alone analysis program. The raw output of sueh network analysis or intrusion 
deteetion programs as Wireshark or Snort could be fed to outside topology generators 
(sueh as those diseussed in Chapter II). These generators eould then be utilized to ereate 
topology, while at the same time, the results of the network tools’ analysis could be used 
to determine segments of attaek, which could then be provided to NTAV3D. 

However, this is still not an easy task. For example, as mentioned above, 
it is extremely diffieult to identify distinct networks from the raw data that a tool sueh as 
Snort provides. Thus, a separate network analysis would be needed for each physical 
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network. This data would then have to be eollated together, allowing for the discovery of 
distinct networks within the data. Furthermore, attempting to collate interconnecting 
networks with different security statuses could prove troublesome. An example could be 
trying to collate the Department of Defense’s secure SIPRNET with the normal 
NIPRNET. While NTAV3D itself would not be a potential vulnerability, since it is only 
providing the visualization, whatever tools are used to try to connect packet flow between 
the networks (e.g., to transfer NTAV3D data from the NIPRNET to the SIPRNET for 
collation) could serve as a gateway for attacks. 

As mentioned above, obtaining this data is quite difficult. Thus, a possible 
solution as relates to NTAV3D could be to allow users of the tool to manually associate 
and provide data about their networks in a similar way that CyberCIEGE does. In this 
case, a user of NTAV3D may already have a good idea of his or her network’s topology, 
and just wants to use NTAV3D’s ability to show three dimensional topology or depict 
attacks. Therefore, the user could manually provide topology data, and such data as 
component names, and even zone locations. Then the data fed to NTAV3D in real-time 
would instead be such information as attack segments and compromised components, 
instead of all data about the network. 

b. Inputting Data Into NTAV3D 

Either manually or through outside analysis tools, once this data is 
obtained, it can be converted into an XML file that the thesis application can load, parse, 
and visualize. 

Eor ease of processing, and to ensure the integrity of data, keeping outputs 
and inputs in XML format throughout the process would be beneficial. Wireshark has 
the built-in ability to export its analysis into an XML file. This can be seen in Eigure 27 
on the following page. 
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Figure 27. The Export File dialog in Wireshark showing the ability to save the file in 
PSML format 


Snort can also output its detections to an XML file via a plug-in, which 
can be installed from http://www.cert.org/kb/snortxml (accessed May 2007). Once these 
network tools have outputs that are in XML format, the aforementioned analysis tools 
could be run to manipulate and provide data to input to NTAV3D. At this point, an 
XSLT, or Extensible Stylesheet Language Transformation, can be performed on the file. 
An XSLT is performed by creating a special kind of XML file. This file contains special 
rules which are processed against an existing XML file to result in a new file being 
created that matches the XSLT file’s criteria. It is this file that can be made to conform 
to the standards of the XML parser of NTAV3D. Again, as mentioned in the previous 
section, an outside tool would have to be utilized to help create the data that this XSLT 
would execute on the fly. This is because XSLTs can translate data syntactically, but not 
semantically. This means the XSLT can change the format of data, but not understand its 
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meaning. For example, the XSLT eannot ereate the topology data where none exists. 
But, by using the outside analysis tools, their data ean be transformed into a format 
NTAV3D ean understand. 

Additionally, there would even be a way to make the transition from 
CyberCIEGE to network tool input seamless to NTAV3D, in other words, no Java eode 
would have to be ehanged. Onee it is ereated, the XSET eould be performed sueh that 
the new file that will be loaded into NTAV3D, based on the protoeol analyzer or 
intrusion deteetion system, is in the same format as a CyberCIEGE file. Erom here, the 
file can be read into the thesis application in the same way as the CyberCIEGE XME file, 
and the visualization can continue. 

D. EVALUATION OF XJ3D 

1. Overall Evaluation 

Overall, Xj3D was successfully utilized to meet the objectives of the thesis. As a 
computer graphics toolkit it, for the most part, produced the desired end result. However, 
while the problem this thesis attempted to solve is not an easy one, at times finding the 
solution became not just a matter of overcoming the problem, but one of overcoming the 
tool chosen. Nonetheless, Xj3D’s benefits mean it has potential to be a power tool for 
producing three dimensional computer programs. 

2. Positive Areas 

a. X3D Knowledge Transfer 

Having a pre-existing knowledge of X3D stand-alone file development 
allowed the authors a slight head start in programming with SAI and Xj3D. Indeed, once 
the SAI is understood, it is fairly simple to see how the SAI maps to X3D elements. This 
is a benefit for those who have worked with stand-alone X3D files, as they can “jump in” 
to SAI development right away. 
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b. Graphics Abstraction 

Another benefit of Xj3D is the layer of abstraction built into it. The Xj3D 
SAI allowed the author to focus on content, rather than having to have a deep knowledge 
of the “inner workings” of how the computer hardware produces a three dimensional 
scene. 


c. Extensibility 

Since Xj3D is the Java implementation of the X3D standard, it is quite 
extensible. What this means is that X3D, and thus Xj3D, has the ability to be expanded, 
customized, and used in almost any way (within context) that a developer wishes. 
Customized graphics elements can be created and reused at the will of the developer, 
rather than being forced to use rigid constructs that may exist with no possibility of 
enhancement. NTAV3D relies on this ability to create whatever graphical element is 
needed in order to visualize the information the way that it does. Additionally, the level 
of extensibility inherent to Xj3D will allow the future expansion of NTAV3D in ways the 
authors may not even have conceived originally. 

3. Areas for Improvement 

a. Documentation 

As noted in Chapter III, Xj3D was chosen over such a package as 
OpenSceneGraph because the authors were already familiar with X3D file development, 
and were more comfortable working with Java. However, while it was noted above this 
familiarity with X3D allowed a fairly quick understanding of the SAI; it did not provide 
assistance with actually implementing the SAI. For one, a clear, up to date 
documentation of how to use the Xj3D SAI in purely programmatic Java is non-existent. 
All documentation on the Xj3D website is almost exactly a year old; (from 2006) 
however, development of Xj3D has been continual throughout the past year. Thus, the 
way the Xj3D SAI is implemented has changed along the way. In some cases in slight 
ways, and in others, enough to change the way a program is created. Indeed, many 
person-hours of programming were “wasted” on trying to figure out how to implement 
X3D nodes that are easily created using X3D file editors. This was mainly due to the 
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lack of documentation, and having to manually investigate the X3D specification for each 
node that the authors wanted to create. Some sort of up to date code example repository 
would help to alleviate this issue, and make using the Xj3D SAI much easier for further 
programmers. 


b. Ease of Programming/Debugging 

Along these same lines, the structure of Xj3D does not lend itself to 
“developer-friendly” programming. For one, the Xj3D SAI objects are not strongly 
typed. An example is that while there is an Xj3D type kn own as “X3DNode,” to actually 
create a specific X3D node in the scene graph, simple strings are utilized, as in the 
example below. 

XSDNode shape = scene .createNode ( "Shape" ) ; 

SFNode shape_geometry = (SFNode) (shape .getField ( "geometry" )) ; 

In this code, while a type of X3DNode is defined as “shape,” the function “createNode” 
that has the string “Shape” as it parameter is still required to actually implement that X3D 
shape node in the scene graph. As can be seen above, this same reliance on strings is 
seen in the way the SAI gets the fields from the just-created shape node (note the 
“getField” method with the string “geometry” as the parameter). The result of this 
weakly typed construction is an increased risk for run-time errors. These errors are 
generally due to mistyping the string needed, or, again due to lack of documentation, not 
knowing which exact string to pass in the appropriate methods to create or get the 
appropriate X3D node or field. 


c. X3D Node Implementation 

Additionally, some aspects of X3D are buggy or not yet supported by the 
Xj3D implementation. One example is “bindable” nodes. Upon launch of NTAV3D, it 
is supposed to jump to a viewpoint, which can be thought of as a specific camera angle 
for viewing the scene. This is done by setting the “bind” value of the viewpoint to “true” 
within the SAI Java code. However, though the code matches examples and “should” 
work, it does not perform as expected. Another example is how some ECMAScript 
nodes are handled. ECMAScript is a scripting language that allows for the automation or 
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manipulation of objects within an established environment. (ECMA, 1999) 
ECMAScript is used within X3D (and thus Xj3D) to provide dynamic control, at run¬ 
time, of the three dimensional objects created within the scene graph. This played a role 
in the navigation scheme. In order to allow keyboard mappings, ECMAScript was 
necessary. However, the Xj3D SAI could not “route” from the X3D node to the script 
successfully. Thus, the authors had to resort to creating an actual X3D file on the fly 
based on viewpoint data, and then integrating it within the scene graph. This process of 
meshing an outside X3D file with an already created scene graph is known as “inlining.” 
This is not optimal, and violated the NTAV3D design goal of manipulating every X3D 
element purely programmatically, and with no X3D files. And while the X3D file is in 
fact created programmatically, and manipulated within Java code, it is not the same as 
actually using the SAI to create the needed nodes; however, the SAI left the authors no 
choice. Hopefully, the continued development of Xj3D will allow the resolution of these 
and similar issues. 
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VI. RECOMMENDATIONS EOR EUTURE WORK AND 

THESIS CONCLUSIONS 

A. RECOMMENDATIONS FOR FUTURE WORK 

This chapter will first outline work for future extensions to NTAV3D, and will 
discuss conclusions in Part B. 

1. Packaging NTAV3D With CyberCIEGE 

Currently, NTAV3D is already able to be packaged with CyberCIEGE. In order 
to accomplish this task, an “x3d” folder is created in the CyberCIEGE root directory. 
Into this folder is plaeed the compiled .elass files that make up NTAV3D. Additionally, 
all of the Xj3D DLL and .jar files should be placed within an “Xj3D” folder within this 
“x3d” folder. Next, the NTAV3D graphies files are eopied to the 
“\CyberCIEGE\game\exec” directory. Once this is aceomplished, the game is launched 
as normal, and the key combination “ctrl-n” is used from within the game to launch 
NTAV3D. 

Since the eapability to be installed and run from within the game already exists, 
the only remaining task that would have to be accomplished to make NTAV3D a fully 
redistributable part of CyberCIEGE would be to include the aforementioned files within 
the CyberCIEGE installer. Xj3D is lieensed under a combination of GNU GPL, GNU 
LGPL, and BSD. (Xj3D Licensing information. May 2007) All of these lieense 
structures allow, in general, the Xj3D libraries to be packaged and redistributed. 

2. NTAV3D in General 

a. Code Enhancement 

Euture work with NTAV3D includes further enhaneements to the 
program. The eode can be optimized for both performance and formatting gains, in terms 
of class structures, class packaging, memory and program flow optimizations ete. 
Additionally, as eaeh new version of Xj3D is released, some of the problems mentioned 
in the previous chapter may be fixed. Thus, it would be benefieial to eontinually test the 
NTAV3D codebase against eaeh new snapshot release of Xj3D. 
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One beneficial modification would be to change the code such that a trail 
is left during an asset attack so that the user is able to see the entire path that was taken 
without having to remember it. One method for achieving this would be to have the line 
segments change color as the information passes along the line segment. Another 
solution would be to add a bread crumb trail using hash marks behind the information as 
is travels along. 

b. Platform Testing 

Additionally, the open source, multi-platform nature of NTAV3D could be 
employed. Due to hardware available and development constraints, NTAV3D remain s 
untested on Apple OS X or Linux computers. Further testing could be done on these 
platforms to ensure interoperability. 


c. Portability 

Since NTAV3D is Java-based, it could conceivably be made into a Java 
applet, and distributed via the web within web browsers, thus making network 
visualization quite portable, and perhaps enabling concepts like remote monitoring of 
security in a three dimensional view from anywhere in the world with internet access. 

3. User Studies 

Time did not permit user studies to be carried out. Therefore, it would be 
interesting to see future work carried out that would explore if the network visualizations 
of NTAV3D actually have a measurable benefit to the user. Such studies would also help 
to answer the more general question of whether a three dimensional network visualization 
really does add value to the user experience. 

4. Network Tools 

Utilizing the framework outlined in the previous chapter, work should be done to 
allow NTAV3D to work, perhaps in real-time, with network protocol analyzers and 
intrusion detection systems. 
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B. CONCLUSIONS 

1. Overall Analysis 

This thesis has been sueeessful in aeeomplishing its researeh motivations and 
objeetives. While time did not permit detailed user studies and analysis, the authors feel 
that the thesis’ network visualization applieation provides enhaneement and benefit to 
users of CyberCIEGE. Also, a viable framework was presented that will allow those 
working with network tools to visualize networks, and assoeiated attaeks. Einally, as far 
as ean be determined, NTAV3D is the first network visualization software applieation 
developed utilizing the eombination of XML and Xj3D teehnology. Thus, the resulting 
development proeess allowed for the effieaey of Xj3D as a means for network attaek 
visualization to be sueeessfully evaluated. 

The problem of network visualization is not an easy one to resolve, and it is hoped 
the researeh presented within this thesis will assist other researehers in the form of 
reeommended praetiees and lessons learned. Network administrators will never have all 
of the information needed to prevent network intrusion. However, this thesis never had 
the goal of improving the methods of network intrusion deteetion. Instead, it was 
sueeessful in being able to provide a better context for seeing the information 
administrators do have, and might not have been able to interpret as well without a visual 
eontext. 

2. Enhancement to CyberCIEGE 

The ereation of the thesis’ NTAV3D applieation has provided an enhaneement to 
the gameplay of CyberCIEGE that did not exist previously. Prior to the ereation of 
NTAV3D, CyberCIEGE users were only able to view the networks they had eonstrueted 
in a two dimensional view, and no player interaetion was possible, other than ehanging 
network eonneetions. The player was merely presented with a basie network map. This 
view provided no relation to the “offiee view” of how eomponents were laid out. 
Additionally, due to the nature of the diagram, it was hard to deeipher whieh networks 
eomponents with multiple eonneetions were part of On the eontrary, NTAV3D allows 
the gameplayer the ability to explore the network they have ereated; to “walk through” 
the network’s eonfiguration in a way similar to the physieal offiee during regular 
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gameplay. Figures 28 and 29 show this difference. Figure 28 is the current state of how 
the gameplayer sees the network he or she has created in CyberCIEGE. Conversely, 
Eigure 29 shows the exact same network visualized within NTAV3D. While it is hard to 
capture the experience of “walking” a three dimensional space in prose, the difference 
seen in these figures, which is the ability to virtually move through the network in a three 
dimensional space provides the user with a higher level of interaction than the current 
“flat,” two dimensional view. Additionally, since the locations of the network devices 
map to their locations in the “office view” of CyberCIEGE, the player should be able to 
more easily deduce specifically which network component from the game he or she is 
looking at. 



Eigure 28. View of CyberCIEGE’s current network view 



Eigure 29. A slightly overhead angle of NTAV3D’s view of the same network 
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Besides just providing a mueh improved view of the network topology, NTAV3D 
provides the player with a vastly improved depiction of network attacks. Instead of only 
the generic movie that would play informing the player of an attack, NTAV3D allows the 
player to actually see the information flow resulting from an attack. Depicting this in the 
three dimensional space also allows the player the ability to adjust their view of the attack 
so that they can glean the best understanding of the security issues being taught. This can 
be an invaluable training tool in learning about network security, and will be explained 
more in the section below. 

3. Visualizing Network Attacks 
a. In CyberCIEGE 

Given the information output by CyberCIEGE, users are able to observe 
the path taken by information during asset attacks. By observing the flow of traffic 
during one of these attacks, the user is able to determine which type of attack (integrity or 
secrecy) is occurring. By observing component compromises, players can hypothesize 
the role of flaws, malicious software, and physical attacks in the attack on the asset. 
Similarly, by observing malicious software on components, the player can deduce the 
potential for availability attacks. 



Eigure 30. Overhead view of entire scene during an example asset attack with the 
walls turned off 
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Figure 31. A close up view of the main office during an example asset attack with the 

walls turned off 

Figure 30 and Figure 31 are two different views during an example 
secrecy asset attack. In this example, there is a Trojan horse on a component and the 
attacker is out on the web somewhere. The name of the asset is shown because this is a 
secrecy attack. Because this is just a snap shot, the path taken by the information is not 
visible, but the direction of travel is known because of the orientation of the cone. 

b. In Network Tools 

Once the framework in the previous chapter is implemented, NTAV3D 
has the possibility of being expanded to provide visualization of network attacks detected 
from such programs as Snort. This could become an excellent tool for network security 
professionals, as it would provide them with the increased network awareness to help 
thwart said attack. If network security experts can “see” an attack as its happening, they 
will have a better chance of isolating and stopping it, and preventing similar attacks in the 
future. 


4. Working With Network Tools 

As just stated, the framework provided in the previous chapter could provide 
NTAV3D with the means to become an excellent tool for network security professionals. 
The framework could be a viable method for easily utilizing the capabilities of NTAV3D 
to interact with network protocol analyzers, or intrusion detection systems. By 
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harnessing the power of XML, and the pre-existing XML parsing in NTAV3D, the 
software applieation ean suecessfully add inereased network awareness to those charged 
with keeping it secure. 

5. Final Thoughts 

By combining research in network topology and vulnerability visualization, three 
dimensional graphics, and open source programming technologies, this thesis was 
successfully able to provide valuable enhancement to CyberCIEGE. Additionally, with 
the future work outlined previously, this NTAV3D project can be extended to provide 
additional functionality to network security tools. NTAV3D is also one of the first 
programs to utilize solely the Java-based Xj3D SAI to create three dimensional scenes. 
Thus, this thesis has provided contributions to three dimensional graphics programming, 
and the overall goals of improving network security and defense. 
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APPENDIX A. X3D NODE TYPES 


A. LIST OF X3D NODES UTILIZED IN NTAV3D 

The NTAV3D solution utilizes X3D graphies in only pure Java code, without 
manipulating an actual X3D format file. This approach may be a less familiar concept to 
those X3D or VRML developers who usually only work with standard stand-alone X3D 
or VRML files. Therefore, for reference, the following is a list of the X3D nodes that 
were implemented within NTAV3D. To understand how each node was implemented, 
refer to code snippets included throughout this document, the selected classes in 
Appendix B, or the NTAV3D source, which is available for review. For more 
information on these nodes, refer to the table derived from the X3D specification found at 

http://www.realism.com/Web3D/x3d/nodeReference.html (last accessed, April 30, 2007). 


X3D nodes implemented within NTAV3D listed alphabetically: 


• 

Appearance 

• Material 

• 

Billboard 

• MovieTexture 

• 

BooleanSequencer 

• Navigationinfo 

• 

BooleanTimeTrigger 

• Positioninterpolator 

• 

Box 

• ProximitySensor 

• 

Color 

• Script 

• 

Cone 

• Shape 

• 

Coordinate 

• Sphere 

• 

Cylinder 

• Switch 

• 

Geo Viewpoint 

• Text 

• 

Group 

• TextureCoordinate 

• 

ImageTexture 

• TimeSensor 

• 

IndexedFaceSet 

• TouchSensor 

• 

Inline 

• Transform 

• 

Integers equenc er 

• Viewpoint 

• 

IntegerTimeTrigger 

• Worldinfo 

• 

KeySensor 
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APPENDIX B. SELECTED XJ3D JAVA CODE 


A. PARSEXML CLASS (EXCERPT) 

package utility; 

// Core Java APIs 
import geoNodes. Attackericon; 
import geoNodes. Cloud; 
import geoNodes . NodeStorage; 
import geoNodes. WallCreator; 

import java. io.File; 
import java. io. lOException; 

import org. w3c. dom. Document; 
import org. w3c. dom. Element; 
import org. w3c. dom. Node; 
import org. w3c. dom. NodeList; 
import org. web3d. x3d. sai . MFString; 
import org. web3d. x3d. sai . X3DNode; 
import org. web3d. x3d. sai . X3DScene; 
import org. xml. sax. SAXException; 

import com.sun.org.apache.xerces.internal.parsers.DOMParser; 

import dataNodes. AttackStorage; 
import dataNodes.CompromiseStorage; 
import dataNodes. Network; 
import dataNodes . NetworkStorage; 

public class ParseXML { 

public ParseXML (X3DScene scene, File parseFile) { 
this .scene = scene; 
this . parseFile = parseFile; 

} 


private X3DScene scene; 

File parseFile; 

private static int hold = 0; 
private static int holdnet = 0; 

private NodeStorage nodeStorage = new NodeStorage () ; 

private CompromiseStorage compromiseStorage = new CompromiseStorage () ; 
private AttackStorage attackStorage = new AttackStorage () ; 
private NetworkStorage networkStorage = new NetworkStorage () ; 
private WallCreator wallCreator [ ] = new WallCreator [ 1 ] ; 

private float maxX = 0 ; 
private float minX = 0; 
private float minZ = 0; 
private float maxZ = 0; 
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private 

boolean 

internetExist = false; 


private 

boolean 

leasedExist = false; 


private 

boolean 

remoteInterExist = false; 


private 

boolean 

remoteLeasedExist = false; 


private 

int internetEl = -1; 


private 

int leasedEl = -1; 


private 

float [] 

mainSite; 


private 

float [] 

remoteSite; 


private 

Network remoteinternet; 


private 

Network remoteLeased; 


private 

float [] 

internetLinep; 


private 

float [] 

leasedLinep; 


private 

float [ ] 

mainInternetEnd = new float 

[3] ; 

private 

float [] 

mainLeasedEnd = new float [3; 

1; 

private 

float [ ] 

remoteInternetStart = new 

float [ 3 

private 

float [ ] 

remoteLeasedStart = new float[3]; 

public 

void parse () { 



try { 

// Create a DOM Parser 

DOMParser parser = new DOMParserO; 

// Parse the incoming file (passed from Main) 
parser. parse (parseFile . toURI ( ) .toStringO ) ; 

// Obtain the document 

Document doc = parser.getDocumentO; 

parseDocument (doc) ; 

} catch (lOException ioe) { 

ioe . printStackTrace () ; 

} catch (SAXException saxe) { 

saxe . printStackTrace () ; 

} 

} 

private void parseDocument (Document doc) { 

{ 

minX = findMinX (doc) ; 
maxX = findMaxX (doc) ; 

minZ = findMinZ (doc) ; 
maxZ = findMaxZ (doc) ; 

mainSite = flndSite (doc, 0); 

remoteSite = findSite (doc, 999); 
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new MovingViewpoint(mainSite, remoteSite) ; 

// float z = (rainZ + raaxZ) / 2; 
float z = maxZ; 
float y = -2; 
float y2 = -2.5f; 

remoteinternet = new Network (scene) ; 
remoteLeased = new Network (scene) ; 

NodeList netNodeLst = doc. getElementsByTagName ( "network” ) ; 

// adding main pipes 

for (int X = 0; x < netNodeLst. getLength () ; x++) { 

networkStorage .setNetworkArr (holdnet, scene) ; 

Node netFstNode = netNodeLst .item (x) ; 

if (netFstNode .getNodeType () == Node . ELEMENT_NODE) { 

Element netNameElmnt = (Element) netFstNode; 

NodeList netNmElmntLst = netNameElmnt 

. getElementsByTagName ( "networkName" ) ; 

Element netNmElmnt = (Element) netNmElmntLst. item ( 0 ) ; 
NodeList netName = netNmElmnt. getChildNodes () ; 
networkStorage . getNetworkArrEI (holdnet) . setNetworkName ( 
(netName .item (0) ) .getNodeValue () ) ; 

NodeList netColElmntLst = netNameElmnt 
. getElementsByTagName ( "color" ) ; 

Element netColElmnt = (Element) netColElmntLst. item ( 0 ) ; 
NodeList netColor = netColElmnt. getChildNodes () ; 
networkStorage . getNetworkArrEI (holdnet) .setColor ( 

(netColor .item (0) ) .getNodeValue () ) ; 

if (networkStorage .getNetworkArrEI (holdnet) 

. getNetworkName () . toLowerCase () 

. contains (" internet ") ) { 

internetEl = holdnet; 
internetExist = true; 

networkStorage . getNetworkArrEI (holdnet) . setLinep ( 

new float[] { mainSite[0], y, z, mainSite[l], 

y. z }); 

mainInternetEnd[ 0 ] = mainSite[l]; 
mainInternetEnd[ 1 ] = y; 
mainInternetEnd[2] = z; 

internetLinep = networkStorage . getNetworkArrEI (holdnet) 
. getLinep () ; 

/ / z ^ z + 2; 

} else if (networkStorage . getNetworkArrEI (holdnet) 

. getNetworkName () . toLowerCase () . contains ( " remote " ) 

I I networkStorage . getNetworkArrEI (holdnet) 

. getNetworkName () . toLowerCase () . contains ( 

"offsite" )) { 

if ( (internetExist == true) 

&& (remoteInterExist == false ) ) { 

remoteinternet. setNetworkName (networkStorage 
. getNetworkArrEI (internetEl) 

. getNetworkName () ) ; 
remoteinternet.setLinep (new float [] { 

remoteSite[ 0 ], y2, remoteSite [2 ], 
remoteSite[ 1 ], y2, remoteSite[ 2 ] }); 
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remoteinternet. setColor (networkStorage 

. getNetworkArrEl (internetEl) . getStrColor () ) ; 

remoteinternet 

. addlnternet ( new float [ ] { 

{{minX + maxX) / 2 + 10), -2, 

{minZ - 10 ) }); 

remoteInterExist = true; 

remoteInternetStart[ 0 ] = remoteSite[ 0 ]; 
remoteInternetStart[ 1 ] = y2; 
remoteInternetStart[2] = remoteSite[2]; 

// remoteSite[2] = remoteSite[2] + 2; 
y2 = y2 - l,25f; 

} 

networkStorage . getNetworkArrEl (holdnet) . setLinep ( 

new float[] { remoteSite[ 0 ], y2, remoteSite[2], 
remoteSite[ 1 ], y2, remoteSite[2] }); 

// remoteSite[2] = remoteSite[2] + 2; 
y2 = y2 - 1.25f; 

} else { 

networkStorage . getNetworkArrEl (holdnet) . setLinep ( 

new float [] { mainSite[0], y, z, mainSite[l], 

y. z }); 

II z = z + 2; 


if (networkStorage .getNetworkArrEl (holdnet) 

. getNetworkName () . toLowerCase () . contains (" leased" ) ) { 

leasedEl = holdnet; 
leasedExist = true; 

networkStorage . getNetworkArrEl (holdnet) . setLinep ( 

new float [] { mainSite[0], y, z, mainSite[l], 

y. z }); 

mainLeasedEnd[ 0 ] = mainSite[l]; 
mainLeasedEnd[ 1 ] = y; 
mainLeasedEnd[2] = z; 

leasedLinep = networkStorage . getNetworkArrEl (holdnet) 

. getLinep () ; 

/ / z ^ z + 2; 

} else if ( (leasedExist == true) 

&& (remoteLeasedExist == false) ) { 

remoteLeased.setNetworkName (networkStorage 

. getNetworkArrEl (leasedEl) . getNetworkName () ) ; 

remoteLeased 

.setLinep (new float [] { remoteSite [0] , y2, 

remoteSite[2], remoteSite[ 1 ], y2, 
remoteSite[2] }); 

remoteLeased.setColor (networkStorage . getNetworkArrEl ( 
leasedEl) . getStrColor () ) ; 
remoteLeased. addNode () ; 
remoteLeasedExist = true; 
remoteLeasedStart[0] = remoteSite[0]; 
remoteLeasedStart[ 1 ] = y2; 
remoteLeasedStart[ 2 ] = remoteSite[ 2 ]; 

// remoteSite[2] = 

// remoteSite[2] + 2; 
y2 = y2 - 1.25f; 

} 

if (holdnet == internetEl) { 

networkStorage . getNetworkArrEl (x) . addlnternet ( 

new float [] { ( (minX + maxX) / 2 + 10) , -2, 

(minZ - 10 ) } ) ; 

} else { 

networkStorage . getNetworkArrEl (holdnet) . addNode () ; 

} 


y = y - 1.25f; 
holdnet++; 
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networkStorage . setNetworkArr (holdnet, scene) ; 
networkStorage . getNetworkArrEl {holdnet) . setColor {"0x00000000") ; 

networkStorage . getNetworkArrEl (holdnet) . setNetworkName ( 

"NullNet7834" ); 


networkStorage . getNetworkArrEl (holdnet) 
new float [] { 0 , 0 , 0 , 0 , 0 , 0 


. setLinep ( 

}) ; 


{ 

NodeList nodeLst = doc . getElementsByTagName (" component ") ; 

for (int X = 0; x < nodeLst .getLength () ; x++) { 

nodeStorage . setBoxArr (hold, scene, new float[] { 0, 0, 0 }, 

new float [] { 0, 0, 0, 0 }, new float [] { 0.5f, 0.5f, 

0 . 5 f }, new float [] { 0.8f, 0.8f, 0.7f }); 

Node fstNode = nodeLst .item (x) ; 


if (fstNode .getNodeXype () == Node .ELEMENT_NODE) { 

Element comNameElmnt = (Element) fstNode; 

NodeList comNmElmntLst = comNameElmnt 

. getElementsByTagName ( " componentName" ) ; 

Element comNmElmnt = (Element) comNmElmntLst. item ( 0 ) ; 
NodeList comName = comNmElmnt. getChildNodes () ; 
nodeStorage . getBoxArrEl (hold) . setCompName ( 

(comName . item ( 0 ) ) . getNodeValue ( ) ) ; 


NodeList comBaseNmElmntLst = comNameElmnt 

. getElementsByTagName ( " componentBase" ) ; 

Element comBaseNmElmnt = (Element) comBaseNmElmntLst 
. item { 0 ) ; 

NodeList comBaseName = comBaseNmElmnt. getChildNodes () ; 

nodeStorage . getBoxArrEl (hold) . setCompBase ( 

(comBaseName .item (0) ) . getNodeValue () ) ; 


NodeList assetNmElmntLst = comNameElmnt 
. getElementsByTagName ( "assetName" ) ; 

Element assetNmElmnt = (Element) assetNmElmntLst. item ( 0 ) 
try { 


NodeList assetName = assetNmElmnt. getChildNodes () ; 
nodeStorage . getBoxArrEl (hold) . setAsset ( 

(assetName .item ( 0 ) ) . getNodeValue () ) ; 

} catch (NullPointerException e) { 

nodeStorage . getBoxArrEl (hold) . setAsset ( " " ) ; 

} 

if (nodeStorage .getBoxArrEl (hold) .getCompBase () 

.toLowerCase () . contains ( "router" ) 

I I nodeStorage . getBoxArrEl (hold) . getCompBase () 
.toLowerCase () .contains ( "flipper" ) 

I I nodeStorage . getBoxArrEl (hold) . getCompBase () 

. toLowerCase () . contains ( " asbestos " ) 

I I nodeStorage . getBoxArrEl (hold) . getCompBase () 

. toLowerCase () . contains ( "linkcrypt" ) ) { 

nodeStorage . getBoxArrEl (hold) . setCompType ( 2 ) ; 
nodeStorage . getBoxArrEl (hold) . setScal ( 

new float [] { 0.5f, 0,15f, 0.5f }); 

} else if (nodeStorage . getBoxArrEl (hold) .getCompBase () 

. toLowerCase () . contains ( "desktop" ) 

I I nodeStorage . getBoxArrEl (hold) . getCompBase () 

. toLowerCase () . contains ( "green" ) 

I I nodeStorage . getBoxArrEl (hold) . getCompBase () 
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. toLowerCase () . contains ("lunitos") ) { 

nodeStorage . getBoxArrEI (hold) . setCompType ( 3 ) ; 
nodeStorage . getBoxArrEI (hold) . setScal ( 

new float [] { 0.3f, 0,6f, 0,4f }); 

} else if (nodeStorage . getBoxArrEI (hold) .getCompBase () 
. toLowerCase () . contains ( " s e rve r " ) ) { 

nodeStorage . getBoxArrEI (hold) . setCompType ( 1 ) ; 

} 


NodeList netNmElmntLst = comNameElmnt 

. getElementsByTagName ( "networkName" ) ; 
for (int y = 0; y < netNmElmntLst .getLength () ; y++) { 

Element netNmElmnt = (Element) netNmElmntLst .item (y) 
NodeList netName = netNmElmnt. getChildNodes () ; 
nodeStorage . getBoxArrEI (hold) . setNetworks (y, 

(netName .item (0) ) . getNodeValue () ) ; 


B. WALLCREATOR CLASS 


package geoNodes; 

import org. web3d. x3d. sal. MFInt32; 
import org. web3d. x3d. sal. MFNode; 
import org. web3d. x3d. sal. MFString; 
import org. web3d. x3d. sal. MFVec3f; 
import org. web3d. x3d. sal. SFBool; 
import org. web3d. x3d. sal. SFColor; 
import org. web3d. x3d. sai . SFFloat; 
import org. web3d. x3d. sai . SFInt32; 
import org. web3d. x3d. sai . SFNode; 
import org. web3d. x3d. sai . SFVecSf; 
import org. web3d. x3d. sai . X3DNode; 
import org. web3d. x3d. sai . XSDScene; 

public class WallCreator { 

private XSDScene scene; 

private float [] corner 1; 

private float [] corners ; 

private float [] col; 

private float transparency; 

private String [] zoneName = { }; 

public WallCreator () { 

} 


public WallCreator (XSDScene scene, float [] inputl, float [] inputs) { 
this . scene = scene; 
this .cornerl = inputl; 
this .corners = inputs; 
float[] color = { .8f, .8f, .8f }; 
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this .col = color; 

float transp = .95f; 

this •transparency = transp; 


} 

public void setZoneName (String name) { 
this. zoneName[0] = name; 

} 


public String getZoneName () { 

return this. zoneName [0] ; 

} 

public float [ ] getXCoords () { 

return new float [] { cornerl[0], corner2[0] }; 

} 


public void addNode () { 

XSDNode switchNode = (XSDNode) scene . createNode (" Switch" ) ; 

MFNode switch_children = (MFNode) switchNode.getField( "children" ); 
switch_children.clear(); 

SFInt32 whichChoice = {SFInt32) switchNode.getField{ "whichChoice ") ; 
whichChoice.setValue( 0 ); 

X3DNode tr = (X3DNode) scene.createNode( "Transform" ); 

MFNode tran_children = (MFNode) tr.getField( "children" ); 
tran_children.clear(); 

X3DNode shape = scene.createNode (" Shape ") ; 

SFNode shape_geometry = (SFNode) (shape.getField( "geometry" )); 

X3DNode box = scene.createNode (" IndexedFaceSet ") ; 

SFBool solid = (SFBool) box.getField (" solid" ); 
solid. setValue (false) ; 

SFBool convex = (SFBool) box.getField( "convex" ); 
convex.setValue (false) ; 

X3DNode appearance = scene.createNode( "Appearance ") ; 

SFNode shape_appearance = (SFNode) (shape.getField( "appearance" )); 

SFNode appear_material = (SFNode) (appearance.getField( "material" )); 

X3DNode material = scene.createNode( "Material ") ; 

SFColor mat_color = (SFColor) (material.getField( "diffuseColor" )); 
mat_color.setValue(col); 

SFFloat mat_transparency = (SFFloat) (material.getField( "transparency ")) ; 
mat_transparency.setValue(transparency) ; 
appear_material.setValue(material) ; 

MFInt32 coord_index = (MFInt32) (box.getField( "coordindex" )); 

coord_index.setValue( 30 , new int[] { 4 , 5 , 1, 0, 4, -1, 5, 6, 2 , 1, 5, -1, 6, 1 , 3, 
2, 6, -1, 1 , 4 , 0, 3, 1 , -1, 0, 3, 2, 1, 0, -1, }); 

SFNode line_coord = (SFNode) (box.getField( "coord" )); 

X3DNode coordinate = scene.createNode( "Coordinate" ); 

MFVec3f point_value = (MFVec3f) (coordinate.getField( "point ")) ; 
point_value . setValue ( 8 , new float[] { this . cornerl [ 0 ] , -1, 
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}) ; 

line_coord.setValue(coordinate); 

// TouchSensor ****Important***** 

X3DNode touchSensor = (X3DNode) scene.createNode( "TouchSensor ") ; 
scene.addRootNode(touchSensor); 

shape_appearance.setValue(appearance) ; 
shape_geometry.setValue(box); 
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tran_children.append(shape); 
tran_children.append(touchSensor); 
switch_children.append(tr); 
scene.addRootNode(switchNode); 

// KeySensor 

XSDNode keySensor = (XSDNode) scene.createNode( "KeySensor ") ; 
scene.addRootNode(keySensor); 

// BooleanFilterl 

XSDNode bfl = (XSDNode) scene.createNode( "BooleanFilter" ); 
scene.addRootNode(bf1); 

// BooleanFilter2 

XSDNode bf2 = (XSDNode) scene.createNode( "BooleanFilter ") ; 
scene.addRootNode(bf2); 

// BooleanFilterS 

XSDNode bfS = (XSDNode) scene.createNode( "BooleanFilter ") ; 
scene.addRootNode(bfS); 

// IntegerTriggers for turning walls on/off 

XSDNode triggerOn = (XSDNode) scene.createNode (" IntegerTrigger" ); 
SFIntS2 integerKeyOn = (SFIntS2) triggerOn.getField (" integerKey" ); 
integerKeyOn.setValue( 0 ); 
scene.addRootNode(triggerOn); 

XSDNode triggerOff = (XSDNode) scene.createNode( "IntegerTrigger" ); 
SFIntS2 integerKeyOff = (SFIntS2) triggerOff.getField (" integerKey ") ; 
integerKeyOff.setValue (-1 ); 
scene.addRootNode(triggerOff); 

// IntegerTriggers for mouseover text 

XSDNode triggerTextOn = (XSDNode) scene.createNode( "IntegerTrigger" ); 
SFIntS2 integerKeyOnText = (SFIntS2) triggerTextOn 
.getField( "integerKey" ); 
integerKeyOnText.setValue( 0 ); 
scene.addRootNode(triggerTextOn); 

XSDNode triggerTextOff = (XSDNode) scene.createNode( "IntegerTrigger" ) 
SFIntS2 integerKeyOffText = (SFIntS2) triggerTextOff 
.getField( "integerKey" ); 
integerKeyOffText.setValue (-1 ); 
scene.addRootNode(triggerTextOff); 

// Switch Node for mouse-over text 

XSDNode switchNodeText = (XSDNode) scene.createNode( "Switch" ); 

MFNode switchText_children = (MFNode) switchNodeText 
.getField( "children" ); 
switchText_children.clear(); 

SFIntS2 whichChoiceText = (SFIntS2) switchNodeText 
.getField( "whichChoice " ); 
whichChoiceText.setValue(-1); 

// Billboard for text 

XSDNode bb = (XSDNode) scene.createNode( "Billboard" ); 

SFVecSf rotationAxis = (SFVecSf) bb.getField( "axisOfRotation" ); 
rotationAxis . setValue (new float [ ] { 0, 1, 0 }); 

MFNode bill_children = (MFNode) bb.getField( "children" ); 
bill_children.clear(); 

// Transform to locate text 

XSDNode tr2 = (XSDNode) scene.createNode( "Transform" ); 

SFVecSf translations = (SFVecSf) tr2.getField( "translation" ); 
translations . setValue (new float [ ] { 

(this . cornerl [ 0 ] + this . corners [ 0 ] ) / 2.Of, 1.5f, 

(this .cornerl[l] + 1.5f) }); 

SFVecSf scales = (SFVecSf) tr2.getField (" scale ") ; 
scales . setValue (new float [] { 2,5f, 2,5f, ,5f }); 

MFNode tran_children2 = (MFNode) trS.getField( "children" ); 
tran_children2.clear(); 
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// Create text shape 

XSDNode shape2 = scene.createNode ("Shape") ; 

SFNode shape_geometry2 = (SFNode) (shape2.getField( "geometry" )); 
XSDNode text = scene.createNode( "Text") ; 

MFString words = (MFString) (text.getField( "string" )); 
words.setValue(zoneName.length, zoneName); 

// Justify text for middle middle 

XSDNode fontStyle = (XSDNode) scene.createNode{ "FontStyle" ); 

SFNode text_justify = (SFNode) text.getField( "fontStyle" ); 

MFString justify = (MFString) fontStyle.getField ("justify") ; 
justify.setValue(2, new String[] { "MIDDLE", "MIDDLE" }); 
text_justify.setValue(fontStyle); 

XSDNode appearance2 = scene.createNode( "Appearance") ; 

SFNode shape_appearance2 = (SFNode) (shape2.getField( "appearance" )); 
SFNode appear_material2 = (SFNode) (appearance2.getField( "material" )) 
XSDNode material2 = scene.createNode( "Material") ; 

SFColor mat_color2 = (SFColor) (material2.getField( "diffuseColor" )); 

mat_color2.setValue (new float [] { 1, 1, 1 }); 

appear_material2.setValue(material2) ; 

shape_appearance2.setValue(appearance2); 

shape_geometry2.setValue(text); 

bill_children.append(shape2); 

tran_children2.append(bb); 

switchText_children.append(tr2); 

scene.addRootNode(switchNodeText); 

// Routes 

scene.addRoute(keySensor, "altKey", bfl, "set_boolean" ); 
scene.addRoute(keySensor, "controlKey" , bf2, "set_boolean" ); 
scene.addRoute(bfl, "inputTrue" , triggerOff, "set_boolean" ); 
scene.addRoute(bf2, "inputTrue" , triggerOn, "set_boolean" ); 
scene.addRoute(triggerOff, "triggerValue" , switchNode, 

"set_whichChoice" ); 

scene 

.addRoute(triggerOn, "triggerValue" , switchNode, 

"set_whichChoice" ); 

scene.addRoute(touchSensor, "isOver", bf3, "set_boolean" ); 
scene.addRoute(bf3, "inputTrue" , triggerTextOn, "set_boolean" ); 
scene.addRoute(bf3, "inputFalse" , triggerTextOff, "set_boolean" ); 
scene.addRoute(triggerTextOn, "triggerValue", switchNodeText, 

"set_whichChoice" ); 

scene.addRoute (triggerTextOff, "triggerValue" , switchNodeText, 

"set_whichChoice" ); 


C. ATTACKERICON CLASS 

package geoNodes; 

import org. web3d. x3d. sai . MFInt32; 
import org. web3d. x3d. sai . MFNode; 
import org. web3d. x3d. sai . MFString; 
import org. web3d. x3d. sai . MFVec2f; 
import org. web3d. x3d. sai . MFVecSf; 
import org. web3d. x3d. sai . SFBool; 
import org. web3d. x3d. sai . SFColor; 
import org. web3d. x3d. sai . SFFloat; 
import org. web3d. x3d. sai . SFInt32; 
import org. web3d. x3d. sai . SFNode; 
import org. web3d. x3d. sai . SFRotation; 
import org. web3d. x3d. sai . SFVec3f; 
import org. web3d. x3d. sai . X3DNode; 
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import org. web3d. x3d. sai . X3DScene; 
public class Attackericon { 
private X3DScene scene; 

private float [] trans = new float [3]; 
private float [ ] rot = new float [ 4 ] ; 
private float transparency = 0; 
public Attackericon () { 


public Attackericon {X3DScene scene, float [ ] position) { 
this .scene = scene; 
this. trans [0] = position[0] - l.Of; 
this. trans[l] = position[l] - .4f; 
this .trans[2] = position[2]; 


public void addNode () { 

XSDNode tr = (XSDNode) scene . createNode ( "Transform" ) ; 

SFVecSf translation = (SFVecSf) tr. getField { "translation" ) ; 
translation.setValue (trans) ; 

SFRotation rotation = (SFRotation) tr . getField { "rotation" ) ; 
rotation.setValue (rot) ; 

SFVecSf scale = (SFVecSf) t r. getField (" scale" ) ; 
scale. setValue (new float [] { 1.5f, 1.5f, 1 }); 

MFNode tran_children = (MFNode) tr. getField ( "children" ) ; 
tran_children. clear () ; 

// Attacker shape 

X3DNode shape = scene . createNode (" Shape ") ; 

SFNode shape_geometry = (SFNode) (shape . getField ( "geometry" )) ; 

XSDNode attacker = scene . createNode (" IndexedFaceSet ") ; 

SFBool solid = (SFBool) attacker. getField (" solid" ) ; 

solid.setValue (false) ; 

XSDNode appearance = scene . createNode ( "Appearance ") ; 

SFNode shape_appearance = (SFNode) (shape . getField ( "appearance" ) ) ; 

SFNode appear_material = (SFNode) (appearance . getField ( "material " ) ) ; 
XSDNode material = scene . createNode ( "Material ") ; 

SFColor mat_color = (SFColor) (material. getField ( "diffuseColor" )) ; 
mat_color. setValue (new float [] { .2f, .2f, .2f }); 

SFFloat mat_transparency = (SFFloat) (material. getField ( "transparency" ) ) 
mat_t ran spar ency. setValue (transparency) ; 
appear_material. setValue (material) ; 

SFNode appear_texture = null; 

XSDNode image_texture = null; 

MFString textureURL = null; 

appear_texture = (SFNode) (appearance . getField ( "texture" )) ; 
image_texture = scene . createNode (" ImageTexture ") ; 
textureURL = (MFString) (image_texture . getField ( "url ")) ; 
textureURL. setValue ( 1 , new String[] { "images.jpg" }); 
appear_texture . setValue (image_texture) ; 

MFInt32 coord_index = (MFInt32) (attacker.getField (" coordindex" )) ; 
MFInt32 texCoord_index = (MFInt32) (attacker. getField ( "texCoordIndex" )) ; 
coord_index.setValue (coordindex. length, coordindex) ; 
texCoord_index. setValue (textCoordindex. length, textCoordIndex) ; 

SFNode line_coord = (SFNode) (attacker. getField (" coord" )) ; 

SFNode text_coord = (SFNode) (attacker. getField ( "texCoord" )) ; 
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XSDNode coordinate = scene . createNode ( "Coordinate ") ; 

XSDNode textureCoord = scene . createNode ( "TextureCoordinate ") ; 

MFVecSf point_value = (MFVecSf) (coordinate . getField ( "point ")) ; 
MFVec2f textCoord_value = (MFVec2f) (textureCoord. getField ( "point ") ) 
point_value . setValue (points . length / 3, points); 
textCoord_value .setValue (textureCoordinates . length / 2, 
textureCoordinates); 
line_coord.setValue (coordinate) ; 
text_coord.setValue (textureCoord) ; 

// TouchSensor ****Iraportant***** 

XSDNode touchSensor = (XSDNode) scene .createNode ( "TouchSensor" ) ; 
scene . addRootNode (touchSensor) ; 

shape_appearance . setValue (appearance) ; 
shape_geometry. setValue (attacker) ; 
tran_children.append (shape) ; 
tran_children. append (touchSensor) ; 
scene . addRootNode (tr) ; 
scene . updateNamedNode ( "tr" , tr) ; 

// BooleanFilter 

XSDNode bf = (XSDNode) scene . createNode ( "BooleanFilter ") ; 
scene . addRootNode (bf) ; 

// IntegerTriggers 

XSDNode triggerOn = (XSDNode) scene . createNode (" IntegerTrigger" ) ; 
SFInt32 integerKeyOn = (SFInt32) triggerOn . getField (" integerKey" ) ; 
integerKeyOn. setValue ( 0 ) ; 
scene . addRootNode (triggerOn) ; 

XSDNode triggerOff = (XSDNode) scene . createNode (" IntegerTrigger ") ; 
SFInt32 integerKeyOff = (SFInt32) triggerOff.getField (" integerKey" ) ; 
integerKeyOf f. setValue (-1 ) ; 
scene . addRootNode (triggerOf f) ; 

XSDNode switchNode = (XSDNode) scene . createNode (" Switch" ) ; 

MFNode switch_children = (MFNode) switchNode . getField ( "children" ) ; 
switch_children. clear () ; 

SFInt32 whichChoice = (SFInt32) switchNode .getField ( "whichChoice" ) ; 
whichChoice . setValue (-1 ) ; 

String[] inputText = { "Attacker" }; 

XSDNode bb = (XSDNode) scene . createNode ( "Billboard" ) ; 

SFVecSf rotationAxis = (SFVecSf) bb. getField ( "axisOfRotation" ) ; 
rotationAxis. setValue (new float[] { 0, 1, 0 }); 

MFNode bill_children = (MFNode) bb.getField ( "children" ) ; 
bill_children. clear () ; 

XSDNode tr2 = (XSDNode) scene . createNode ( "Transform" ) ; 

SFVecSf translations = (SFVecSf) tr2 . getField ( "translation" ) ; 
translations 

. setValue (new float[] { trans[0], (trans [ 1 ] +4 . 5f ) , trans[2] }) 
SFVecSf scale2 = (SFVecSf) tr2 . getField (" scale" ) ; 
scale2 .setValue (new float[] { 2.5f, 2.5f, .5f }); 

MFNode tran_children2 = (MFNode) tr2 .getField ( "children" ) ; 
tran_children2 . clear () ; 

XSDNode shape2 = scene . createNode (" Shape ") ; 

SFNode shape_geometry2 = (SFNode) (shapeS .getField ("geometry") ) ; 
XSDNode text = scene . createNode ( "Text ") ; 

MFString words = (MFString) (text. getField (" string" )) ; 
words .setValue (inputText. length, inputText) ; 

XSDNode fontStyle = (XSDNode) scene .createNode ( "FontStyle" ) ; 

SFNode text_justify = (SFNode) text. getField (" fontStyle" ) ; 
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MFString justify = (MFString) font Style . getField (" justify") ; 
justify-setValue (2, new String[] { "MIDDLE", "MIDDLE" }); 
text_justify.setValue (fontStyle) ; 

XSDNode appearance2 = scene . createNode ( "Appearance ") ; 

SFNode shape_appearance2 = (SFNode) (shape2 . getField ( "appearance" ) ) ; 
SFNode appear_material2 = (SFNode) (appearance2 . getField ( "material")) ; 
XSDNode material2 = scene . createNode ( "Material") ; 

SFColor mat_color2 = (SFColor) {material2 .getField ( "diffuseColor" )) ; 
mat_color2. setValue (new float[] {0, 0, 1 }); 
appear_material2 . setValue (material2) ; 

shape_appearance2 .setValue (appearance2) ; 
shape_geometry2 . setValue (text) ; 
bill_children. append (shape2) ; 
tran_children2 . append (bb) ; 

switch_children. append (tr2) ; 
scene . addRootNode (switchNode) ; 


scene. addRoute (touchSensor, "isOver", bf, "set_boolean" ); 
scene. addRoute (bf, "inputTrue", triggerOn, "set_boolean" ); 
scene. addRoute (bf, "inputFalse", triggerOff, "set_boolean" ); 
scene 


. addRoute (triggerOn, 
"set_whichChoice" ) 
scene . addRoute (triggerOff, ' 
"set_whichChoice" ) 
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D. PHYSICAL ATTACK CLASS 


package geoNodes; 

import org. webSd. x3d. sai . MFFloat; 
import org. webSd. x3d. sai . MFNode; 
import org. web3d. x3d. sai . MFString; 
import org. web3d. x3d. sai . MFVec3f; 
import org. web3d. x3d. sai . SFBool; 
import org. web3d. x3d. sai . SFColor; 
import org. web3d. x3d. sai . SFNode; 
import org. web3d. x3d. sai . SFTime; 
import org. web3d. x3d. sai . SFVec3f; 
import org. web3d. x3d. sai . XSDNode; 
import org. web3d. x3d. sai . X3DScene; 

public class PhysicalAttack { 


private X3DScene scene; 
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private float [] trans; 


private float [] col; 
public PhysicalAttack () { 


public PhysicalAttack (XSDScene scene, float [] location) { 
this .scene = scene; 
this ■trans = location; 
float [] color = f 1, 1, 1 }; 
this .col = color; 


public void addNode () { 

float [] keys = { 0, .25f, .75f, 1 }; 

float [] keyValues = {1, 1, 1, 1, 0, 0, 1, 0, 0, 1, 1, 1}; 

XSDNode bb = (XSDNode) scene . createNode ( "Billboard" ) ; 

SFVecSf rotationAxis = (SFVecSf) bb. getField ( "axisOfRotation" ) ; 
rotationAxis. setValue (new float[] {0, 1 , 0 }); 

MFNode bill_children = (MFNode) bb.getField ( "children" ) ; 
bill_children. clear () ; 

String[] name = { "Component", "Stolen!" }; 

XSDNode tr2 = (XSDNode) scene . createNode ( "Transform" ) ; 

SFVecSf translation2 = (SFVecSf) tr2 . getField { "translation" ) ; 
trans1ation2 

. setValue (new float [] { (trans [0] - 2), trans [1], trans [2] }); 

SFVecSf scale2 = (SFVecSf) tr2 . getField (" scale" ) ; 
scale2 .setValue (new float[] { 3. Of, 3. Of, 1 }); 

MFNode tran_children2 = (MFNode) tr2 .getField ( "children" ) ; 
tran_children2 . clear () ; 

X3DNode shape2 = scene . createNode (" Shape ") ; 

SFNode shape_geometry2 = (SFNode) (shape2 .getField ("geometry") ) ; 
X3DNode text = scene .createNode ( "Text ") ; 

MFString words = (MFString) (text. getField (" string" )) ; 
words . setValue (name . length, name) ; 

X3DNode fontStyle = (X3DNode) scene . createNode ( "FontStyle ") ; 

SFNode text_justify = (SFNode) text. getField (" fontStyle" ) ; 

MFString justify = (MFString) fontStyle . getField (" justify" ) ; 
justify .setValue (2, new String[] { "MIDDLE", "MIDDLE" }); 
text_justify.setValue (fontStyle) ; 

X3DNode appearance2 = scene . createNode ( "Appearance ") ; 

SFNode shape_appearance2 = (SFNode) (shape2 . getField ( "appearance" ) ) ; 
SFNode appear_material2 = (SFNode) (appearance2 . getField ( "material ") ) 
X3DNode material2 = scene . createNode ( "Material ") ; 

SFColor mat_color2 = (SFColor) (material2 . getField ( "diffuseColor" )) ; 

mat_color2. setValue (new float[] {1, 1, 1 }); 
appear_material2 .setValue (material2) ; 

shape_appearance2 .setValue (appearance2) ; 
shape_geometry2 .setValue (text) ; 
bill_children. append (shape2) ; 
tran_children2 . append (bb) ; 

scene . addRootNode (tr2) ; 

scene . updateNamedNode ( "tr2 " , tr2) ; 

// positioninterpolator 
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XSDNode pi = (XSDNode) scene . createNode ( "Positioninterpolator ") ; 
MFFloat key = (MFFloat) pi . getField ( "key " ) ; 
key. setValue (keys . length, keys) ; 

MFVecSf keyValue = (MFVecSf) pi . getField ( "keyValue" ) ; 
keyValue . setValue ( (keyValues . length) / 3, keyValues) ; 
scene . addRootNode (pi) ; 
scene . updateNamedNode ( "pi " , pi) ; 

// TimeSensor 

XSDNode timeSensor = (XSDNode) scene . createNode ( "TimeSensor ") ; 

SFBool loop = (SFBool) timeSensor. getField (" loop" ) ; 
loop. setValue (true) ; 

SFTime cycleinterval = (SFTime) timeSensor. getField ( "cycleinterval " ) 
cycle Interval. setValue (2.0) ; 
scene . addRootNode (timeSensor) ; 

scene . updateNamedNode ( "timeSensor " , timeSensor) ; 

// Routes 

scene.addRoute (timeSensor, "fraction_changed", pi, "set_fraction" ); 
scene.addRoute (pi, "value_changed" , material2, "diffuseColor " ); 
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APPENDIX C. THESIS CLASS DIAGRAM 


A. THESIS APPLICATION CLASS DIAGRAM 

The following pages contain UML class diagrams for each programmatic package 
of the thesis application. These diagrams allow the classes to be seen at a glace, and to 
see which classes relate to each other. To organize the programming code, classes with 
similar functions are grouped into what are known as “packages.” Due to space 
limitations and to enhance readability, in some cases, the packages are broken up into 
parts for the purposes of these diagrams, but each class in the “parti, 2, etc.” diagram is 
actually all within one package. The following is a brief summary of what each package 
contains. 

sledzCoomesThesis: Contains the “main” method of the program, as well as those 
that setup the Xj3D browsing environment. It also contains the calls to the XML parsing 
class, which starts the process of visualizing whatever is input to NTAV3D. 

dataNodes : Contain classes that hold data about network nodes and network 
attack information. 

geoNodes: Contain the classes that define all of the geometric objects that appear 
in NTAV3D, such as computer, server, and router models, as well as the transparent 
walls, moving cones, etc. 

utility: Contains the main XML parser class, which carries out the bulk of the 
work in parsing the XML file and creating the three dimensional scene graph. The utility 
package also contains various utility classes, such as Java array resizers and the classes 
that interpret positions. 
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sledzCoomesThesis 




SledzCoomesThesisMain 

{ From sledzCoomesThesis } 

Attributes 

private long serialVersionUID = 385452894127295812L 

private X3DScene mainScene 
protected ExternalBrowser x3dBrowser 

Operations 

public SledzCoomesThesisMain( ) 

public X3DScene qetMainScenef ) 

public void setMainScene( X3DScene mainScene ) 

protected ExternalBrowser qetX3dBrowser( ) 

public void mainf String arqsfO..*]) 
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private X3DScene scene 
private float keys[0..*] 
private float keyValues[0..*] 


public Orlentatlonlnterpolator( ) 

public Orientatlonlnterpolator(X3DScene scene, floatkeys[0..*], float keyValues[0..*l) 

public void addNodef) 

public float[0..’] getKeysf ) 

public void setKeys(floatkeys(O..T) 

pubiicfioat(0..*) getKeyVaiuesf ] 

public void se0<eyVaIues( float keyValues[0. *]) 

public XSDScene getScene( ) 

pubiic void setScene(X3DScene scene) 


private X30Scene scene 
private boolean loopCondItion 
private doubie cycieTime 


Operations 

pubiic TimeSensor() 

pubiic 'nmeSensor( xaoscene scene, booiean ioopCondttion, doubie cycieTime) 

pubiic void addNodeC) 

pubiic doubie getCycielimef) 

public void setCycleTimeC double cycieTime] 

pubiic booiean isLoopCondltion() 

public void setLoopCondition( boolean loopCondition) 

public X3DScene getScene( ] 

public void setScene(X3DScene scene) 
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APPENDIX D. SAMPLE XML LILES 


A. CYBERCIEGE XML DOCUMENT TYPE DEFINITION (NETVIEW.DTD) 

<!- 

Name; netView.dtd 
Version: Draft 1.2 
—> 

<!ELEMENT CyberCIEGEnetView ((version, SDFid, network+, mainSite, offEite?, 
eomponentCompromise*, attaok*))> 

<!ELEMENT version (#PCDATA)> 

<!EEEMENT SDFid (#PCDATA)> 

<!- 

Assoeiate eolors with network names to mateh that seen in game. 

— > 

<!ELEMENT network (networkName, oolor)> 

<!ELEMENT mainSite (zoneName, upperEeft, lowerRight, eomponent*, zone*)> 
<!ELEMENT oftEite (zoneName, upperEeft, lowerRight, eomponent*)> 

<!- 

zones ean be nested. 

— > 

<!ELEMENT zone (zoneName, upperEeft, lowerRight, eomponent*, zone*)> 

<!- 

In the future eomponent may inelude 0/S name and eonfiguration settings. In 
initial implementation, assets need not be depieted on other than the eomputer that is 
attaeked. 

— > 

<!ELEMENT eomponent (componentName, eomponentBase, loeation, networkName*, 
assetName*)> 

<!- 

The eomponent name as assigned by player or engine, e.g., "Joe's PC" 

— > 

<!ELEMENT componentName (#PCDATA)> 

<!- 

Identifies the graphics image to use when representing this component 

— > 

<!ELEMENT eomponentBase (#PCDATA)> 

<!- 

Dimensions are between 0 and 100 on each axis. Component locations will all 
tend to have the same "y" component, except when located in a server rack. For now, 
those components floating above each other will be sufficient (i.e., no need to illustrate a 
rack). 

— > 

<! ELEMENT upperEeft (x, z)> 

<! ELEMENT lowerRight (x, z)> 

<! ELEMENT location (x, y, z)> 
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<!ELEMENT x (#PCDATA)> 

<!ELEMENT y (#PCDATA)> 

<!ELEMENT z (#PCDATA)> 

<!EEEMENT networkName (#PCDATA)> 

<!ELEMENT assetName (#PCDATA)> 

<!- 

The componentCompromise pairs identify whieh eomponents should inelude 
whieh attaek type visual representation. There is eurrently no semantie linkage 
between eomponentCompromise and attaeks. 

— > 

<!ELEMENT eomponentCompromise (attaekType, eomponentName)> 

<!ELEMENT attaekType (#PCDATA)> 

<!—<! ELEMENT attaekType (trojanHorse | trapDoor | osElaw | physieal | virus)>— > 

<!- 

The attaek simply illustrates the asset being eompromised. A poliey of "seereey" 
will show information flowing from the asset out throught the networks. A poliey 
of "integrity" will show information flowing from the networks into the asset. If 
no segments are provided, the flow will simply be into and out of the eomponent 
that eontains the asset, and if "attaeker" is present the flow will be to-from the 
attaeker. If attaeker is not present, the flow will be internal to the eomputer (i.e., 
it would be an integrity eompromise driven by malware). 


The segments simply refleet the path the data takes on its way to or from the 
attaeker. Segments are order dependent. If a "attaeker" is present, then the 
eomponentName in the final segment is the eomponent at whieh the attaeker 
reeeives information from seereey attaeks or sends information in integrity 
attaeks. In a typieal seereey ease, information would be depleted as flowing from 
the asset, through a series of networks and eomponents, and then out of the final 
eomponent into an attaeker ieon. If the final segment ineludes a zoneName 
instead of a eomponentName, then the information enters or leaves the final 
network anywhere within the named zone. If there is no named zone or 
eomponent in the final segment then the network will be exernal (either the 
Internet or some network that goes between the main site and the offsite) - in 
whieh ease the attaeker is at the Internet or the other network link. 

— > 


ELEMENT attaek (assetName, poliey, segment*, attaeker?)> 
ELEMENT segment (Network, (eomponentName? | zoneName?))> 
ELEMENT Network (#PCDATA)> 

ELEMENT poliey (#PCDATA)> 

— <!ELEMENT poliey (Seereey | Integrity)>— > 

ELEMENT attaeker (#PCDATA)> 

ELEMENT zoneName (#PCDATA)> 


Color is rgb in hex, e.g., OxEEOOEEOO 


-> 


<!ELEMENT eolor (#PCDATA)> 


no 



B. SAMPLE CYBERCIEGE XML OUTPUT 


<?xml version="1.0"?> 

<!DOCTYPE CyberCIEGEnetView SYSTEM ''netView.dtd"> 
<CyberCIEGEnetV iew> 

<version>0 . 0</version> 

<SDEid>0.0</SDEid> 

<network> 

<networkN ame>Intemet</ networkN ame> 
<color>0xEEEE0000</color> 

</network> 

<network> 

<networkN ame>leased</networkN ame> 
<color>0xEE00EE00</color> 

</network> 

<network> 

<networkN ame>link 1 </ networkN ame> 
<color>0xEEEE7E00</color> 

</network> 

<network> 

<networkN ame>link2</ networkN ame> 
<color>0xEE0000EE</color> 

</network> 

<network> 

<networkN ame>Lan 1 </ networkN ame> 
<color>0xEEEE00EE</color> 

</network> 

<network> 

<networkName>Offsite EAN</networkName> 
<color>0xEEEEEE00</color> 

</network> 

<mainSite> 

<zoneN ame>Entire Office</ zoneName> 

<upperEeft><x>33</x><z>49</z></upperEeft> 

<lowerRight><x>56</x><z>31</z></lowerRight> 

<oomponent> 

<componentName>Joe_ws</oomponentName> 
<componentBase>Blato Desktop Seleot</componentBase> 
<looation><x>35</x><y>l</y><z>36</z></looation> 
<networkN ame>leased</ networkN ame> 
<networkName>Lanl</networkName> 
<assetName>Plans</assetName> 

</oomponent> 

<oomponent> 

<componentName>Lunitos APOS_3</oomponentName> 
<componentBase>Eunitos APOS</componentBase> 
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<location><x>35</x><y>0</y><z>47</z></location> 
<networkN ame>leased</ networkN ame> 

<networkN ame>link 1 </ networkN ame> 

</component> 

<component> 

<componentName>Bit Flipper Border_3</eomponentName> 
<eomponentBase>Bit Flipper Border</eomponentBase> 
<loeation><x>34</x><y>l</y><z>37</z></location> 
<networkN ame>Intemet</ networkN ame> 

<networkN ame>link 1 </ networkN ame> 

<networkN ame>Lan 1 </ networkN ame> 

</component> 

</mainSite> 

<oflBite> 

<zoneN ame>Offsite</ zoneN ame> 
<upperLeft><x>94</x><z>28</z></upperLeft> 

<lowerRight><x> 1 06</x><z>2 1 </z></lowerRight> 

<oomponent> 

<oomponentName>Kim's Workstation</oomponentName> 
<componentBase>Blato Desktop Seleot</componentBase> 
<looation><x>104</x><y>l</y><z>23</z></looation> 
<networkN ame>leased</ networkN ame> 

</oomponent> 

<component> 

<componentName>Lunitos AFOS_2</oomponentName> 
<oomponentBase>Lunitos AFOS</oomponentBase> 
<looation><x>96</x><y>l</y><z>22</z></location> 
<networkName>Offsite LAN</networkName> 
</oomponent> 

<oomponent> 

<componentName>Bit Flipper_2</componentName> 
<componentBase>Bit Flipper</oomponentBase> 
<looation><x>95</x><y>l</y><z>23</z></looation> 
<networkN ame>Intemet</ networkN ame> 
<networkName>Offsite LAN</networkName> 
</component> 

</oflBite> 

</ CyberCIEGEnetV iew> 
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